pylab set function in python 2.4

I'm wondering if set is now a bad name for pylab to be using?

    > +1 for changing it.

    > I've also had this issue bite me when I was hacking together
    > some code and wanted to use a python set. I'd be in favour of
    > changing the pylab set to be called something else, although
    > I don't have any good suggestions about what to change it
    > to...

Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.

JDH

    >> I'm wondering if set is now a bad name for pylab to be using?

    > +1 for changing it.

    > I've also had this issue bite me when I was hacking together
    > some code and wanted to use a python set. I'd be in favour of
    > changing the pylab set to be called something else, although
    > I don't have any good suggestions about what to change it
    > to...

Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.

This sounds like a perfectly valid course of action to me. In the
meantime, if people want to have set refer to python sets and setp refer
to the pylab set function the following should work (untested):

from pylab import *
setp = set
set = __builtins__.set

Tim

JDH

`-

···

On Wed, 18 May 2005, John Hunter <jdhunter@...4...> wrote...

John Hunter wrote:

"Tim" == Tim Leslie <timl@...505...> writes:

    >> I'm wondering if set is now a bad name for pylab to be using?

    > +1 for changing it.

    > I've also had this issue bite me when I was hacking together
    > some code and wanted to use a python set. I'd be in favour of
    > changing the pylab set to be called something else, although
    > I don't have any good suggestions about what to change it
    > to...

Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.

I'd also suggest removing from all example code 'from pylab import *' statements. Frankly, after a while I've completely stopped using 'from foo import *' in _any_ code I write, even small scripts. All I use these days is code like:

import Numeric as N
import scipy as S
import pylab as P

The only place where I think that from-import-* is OK is at an interactive prompt, where you are just doing experiments and not writing reusable code.

Since the examples tend to be the place that people learn from, I think it would be a good idea to encourage safer practices by banning the dangerous import-* idiom from there.

Just my opinion.

Best,

f

Fernando Perez wrote:

John Hunter wrote:

    >> I'm wondering if set is now a bad name for pylab to be using?

    > +1 for changing it.

    > I've also had this issue bite me when I was hacking together
    > some code and wanted to use a python set. I'd be in favour of
    > changing the pylab set to be called something else, although
    > I don't have any good suggestions about what to change it
    > to...

Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.

I'd also suggest removing from all example code 'from pylab import *' statements. Frankly, after a while I've completely stopped using 'from foo import *' in _any_ code I write, even small scripts. All I use these days is code like:

import Numeric as N
import scipy as S
import pylab as P

The only place where I think that from-import-* is OK is at an interactive prompt, where you are just doing experiments and not writing reusable code.

Since the examples tend to be the place that people learn from, I think it would be a good idea to encourage safer practices by banning the dangerous import-* idiom from there.

Just my opinion.

Best,

f

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

As the new learner that Fernando alludes to, I'd like to second his opinion. As we speak, I'm looking through examples I've collected trying to piece together something useful for my work. The namespace conflicts are a huge frustration, especially with regard to numarray/Numeric overlap. As a newbie, this is almost a show stopper. I'll figure it out eventually I hope...

Here's another vote for ditching from import *. As we get more and more experience writing larger python programs, using import * just seems to cause more and more problems. Given the huge variety of modules out there, it's impossible to avoid name conflicts and it's almost impossible to track down conflicts when they occur. We've started instructing/pushing/cajoling our users to do exactly what Fernando has suggested:

import pylab as P

Ted

···

At 10:04 AM 5/18/2005, Derrick Snowden wrote:

Fernando Perez wrote:

John Hunter wrote:

"Tim" == Tim Leslie <timl@...505...> writes:

    >> I'm wondering if set is now a bad name for pylab to be using?

    > +1 for changing it.

    > I've also had this issue bite me when I was hacking together
    > some code and wanted to use a python set. I'd be in favour of
    > changing the pylab set to be called something else, although
    > I don't have any good suggestions about what to change it
    > to...

Ouch, I hadn't thought of this. In the past, consensus has been that
pylab should not override built-ins, eg the previous discussion on
min/max which led us to rename these functions to amin/amax. Changing
set, unfortunately, will break a lot of scripts. I think the best
plan of action is to define a new function pset or setp (setp for "set
property") which has the functionality of the old, and keep set around
for a release or two issuing a warning with a line number so people
can get their existing scripts cleaned up.

I'd also suggest removing from all example code 'from pylab import *' statements. Frankly, after a while I've completely stopped using 'from foo import *' in _any_ code I write, even small scripts. All I use these days is code like:

import Numeric as N
import scipy as S
import pylab as P

The only place where I think that from-import-* is OK is at an interactive prompt, where you are just doing experiments and not writing reusable code.

Since the examples tend to be the place that people learn from, I think it would be a good idea to encourage safer practices by banning the dangerous import-* idiom from there.

Just my opinion.

Best,

f

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

As the new learner that Fernando alludes to, I'd like to second his opinion. As we speak, I'm looking through examples I've collected trying to piece together something useful for my work. The namespace conflicts are a huge frustration, especially with regard to numarray/Numeric overlap. As a newbie, this is almost a show stopper.
I'll figure it out eventually I hope...

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ted Drain Jet Propulsion Laboratory ted.drain@...369...

Fernando Perez wrote:

I'd also suggest removing from all example code 'from pylab import *' statements.

Here here! (hear hear?). I'd really like to see all those "import *"'s go away.

One way to get there is to add much of the functionality of pylab to the OO interface. I really wish I had the time to write an OO-pylab, I think it would be really great, even for interactive use.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...