matplotlib-devel Mailing List for matplotlib (Page 3)

On 4/5/07, Robert Kern <rob...@gm...> wrote:
> Oh, you're requiring setuptools now? I didn't notice that. Cool.
>
> I'd point them here for up-to-date instructions and downloads:
>
> http://cheeseshop.python.org/pypi/setuptools
Thanks Robert for the insight! I updated the installation
instructions for setuptools in setup.py to point to the link you
mentioned.
Unfortunately, the official docs for setuptools
(http://peak.telecommunity.com/DevCenter/setuptools) point to
downloading ez_setup.py --- nowhere near mentioning it's deprecated.
Still, being able to point users to download one file (ez_setup.py),
and run it to install setuptools on *every* system is very tempting.
Especially, when you can point them to just run:
python ez_setup.py matplotlib
to install the latest version of matplotlib.
Edin

It appears Circle has lost it's verts attribute, but not all of the 
references.
-r
PyMate r6190 running Python 2.5 (/usr/bin/env python)
 >>> picker_demo.py
Exception in Tkinter callback
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/lib-tk/Tkinter.py", line 1403, in __call__
 return self.func(*args)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_tkagg.py", line 
151, in resize
 self.show()
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_tkagg.py", line 
154, in draw
 FigureCanvasAgg.draw(self)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/backends/backend_agg.py", line 
392, in draw
 self.figure.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/figure.py", line 574, in draw
 for a in self.axes: a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/axes.py", line 1281, in draw
 a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/matplotlib/patches.py", line 764, in draw
 tverts = self.get_transform().seq_xy_tups(self.verts) # center 
is first vert
AttributeError: Circle instance has no attribute 'verts'
-----
Rob Hetland, Associate Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Robert Kern wrote:
> Oh, you're requiring setuptools now? I didn't notice that. Cool.
> 
Just for Python 2.3 so that we could sanitize the setup.py a little.
(Namely for the backport of the package_data field to setup().) It's not
required for Python >= 2.4 since package_data is already in stock
distutils there.

>
> I don't quite understand: what kind of "c" are you passing in, what is
> the original code doing with it, and what should it do with it? (I find
> both the original and the suggested code hard to understand, which makes
> me think that neither is actually what we want.)
c is a named argument of the scatter method for the colors, but it is
modified to get the real "colors" argument.
I think that what we want may be the following:
>
> try:
> colors = colorConverter.to_rgba_list(c, alpha)
> except TypeError:
> colors = None # generate colors later by applying a colormap to c
>
> Part of what makes all this hard to understand is that in the None case,
> colors are generated from c far down in the code, out of sight of this
> initial processing. Hence the comment.
>
> OK, now I see that what I proposed won't work until I rip out the
> long-deprecated float-as-grey option. Looks like a good time for me to
> do it.
>
> Eric
If you say so :)
Matthieu

Matthieu Brucher wrote:
> Hi,
> 
> I'm trying to display a scatter plot in 3D, and it calls the 2D scatter 
> plot, in axes.py. This method tests for validity of the color argument 
> in line 3777 :
> 
> if not is_string_like(c) and iterable(c) and len(c)==len(x):
> colors = None
> else:
> colors = ( colorConverter.to_rgba(c, alpha), )
> 
> The trick is that if c is a numpy array, it passes the test, and thus no 
> color is selected. If I get rid of the test and use a Nx3 array, the 
> plot is correctly displayed.
> 
> I suppose that we could make it :
> 
> if not (is_string_like(c) or is_numlike(c)) and iterable(c) and 
> len(c)==len(x):
> colors = None
> else:
> colors = ( colorConverter.to_rgba(c, alpha), )
> 
> ?
I don't quite understand: what kind of "c" are you passing in, what is 
the original code doing with it, and what should it do with it? (I find 
both the original and the suggested code hard to understand, which makes 
me think that neither is actually what we want.)
I think that what we want may be the following:
try:
 colors = colorConverter.to_rgba_list(c, alpha)
except TypeError:
 colors = None # generate colors later by applying a colormap to c
Part of what makes all this hard to understand is that in the None case, 
colors are generated from c far down in the code, out of sight of this 
initial processing. Hence the comment.
OK, now I see that what I proposed won't work until I rip out the 
long-deprecated float-as-grey option. Looks like a good time for me to 
do it.
Eric
> 
> I found a little error in a docstring, if this proposal is OK, I'll send 
> a diff patch to the list.
> 
> Matthieu
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On 4/5/07, Robert Kern <rob...@gm...> wrote:
> 
>> The purpose of ez_setup.py was to give people a migration path such that they
>> could write project that used setuptools, but ensure that their users wouldn't
>> have to go install another package themselves.
>>
>> It's deprecated now. Don't use it.
> 
> So from this I take that our current approach advising people to use
> ez_setup.pu if setuptools are not available is also a bad idea.
> Currently we
> 
> try: import setuptools
> except ImportError:
> raise SystemExit("""\
> matplotlib requires setuptools for installation. Please download
> http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
> you are doing a system wide install) to install the proper version of
> setuptools for your system. If this is your first time upgrading
> matplotlib with the new setuptools requirement, you must delete the
> old matplotlib install directory.""")
Oh, you're requiring setuptools now? I didn't notice that. Cool.
I'd point them here for up-to-date instructions and downloads:
 http://cheeseshop.python.org/pypi/setuptools
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On 4/5/07, Robert Kern <rob...@gm...> wrote:
> The purpose of ez_setup.py was to give people a migration path such that they
> could write project that used setuptools, but ensure that their users wouldn't
> have to go install another package themselves.
>
> It's deprecated now. Don't use it.
So from this I take that our current approach advising people to use
ez_setup.pu if setuptools are not available is also a bad idea.
Currently we
 try: import setuptools
 except ImportError:
 raise SystemExit("""\
matplotlib requires setuptools for installation. Please download
http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
you are doing a system wide install) to install the proper version of
setuptools for your system. If this is your first time upgrading
matplotlib with the new setuptools requirement, you must delete the
old matplotlib install directory.""")

Robert Kern wrote:
> John Hunter wrote:
> 
>> On 4/5/07, Edin Salkovic <edi...@gm...> wrote:
>>
>> 
>>> This would make installing setuptools even easier, since the newest
>>> ez_setup/seuptools would be downloaded by the user/developer every
>>> time a "svn update;python setup.py install" is issued.
>>>
>>> Are the above changes OK?
>>> 
>> I'm not sure I see the benefit here -- what does it buy us to insure
>> that we always have the latest ez_setup in our tree?
>> 
>
> The purpose of ez_setup.py was to give people a migration path such that they
> could write project that used setuptools, but ensure that their users wouldn't
> have to go install another package themselves.
>
> It's deprecated now. Don't use it.
> 
Furthermore, even if it weren't deprecated, it seems to me a bad idea.
(Perhaps that's why it's deprecated.) If a user needs to install
setuptools, IMO, the user should know that. For example, on most linux
distributions, the right thing to do would be to install that
distribution's package of setuptools.

Hi,
I'm trying to display a scatter plot in 3D, and it calls the 2D scatter
plot, in axes.py. This method tests for validity of the color argument in
line 3777 :
 if not is_string_like(c) and iterable(c) and len(c)==len(x):
 colors = None
 else:
 colors = ( colorConverter.to_rgba(c, alpha), )
The trick is that if c is a numpy array, it passes the test, and thus no
color is selected. If I get rid of the test and use a Nx3 array, the plot is
correctly displayed.
I suppose that we could make it :
 if not (is_string_like(c) or is_numlike(c)) and iterable(c) and
len(c)==len(x):
 colors = None
 else:
 colors = ( colorConverter.to_rgba(c, alpha), )
?
I found a little error in a docstring, if this proposal is OK, I'll send a
diff patch to the list.
Matthieu

John Hunter wrote:
> On 4/5/07, Edin Salkovic <edi...@gm...> wrote:
> 
>> This would make installing setuptools even easier, since the newest
>> ez_setup/seuptools would be downloaded by the user/developer every
>> time a "svn update;python setup.py install" is issued.
>>
>> Are the above changes OK?
> 
> I'm not sure I see the benefit here -- what does it buy us to insure
> that we always have the latest ez_setup in our tree?
The purpose of ez_setup.py was to give people a migration path such that they
could write project that used setuptools, but ensure that their users wouldn't
have to go install another package themselves.
It's deprecated now. Don't use it.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On 4/5/07, Edin Salkovic <edi...@gm...> wrote:
> This would make installing setuptools even easier, since the newest
> ez_setup/seuptools would be downloaded by the user/developer every
> time a "svn update;python setup.py install" is issued.
>
> Are the above changes OK?
I'm not sure I see the benefit here -- what does it buy us to insure
that we always have the latest ez_setup in our tree?
JDH

On Thursday 05 April 2007 06:44:36 am Edin Salkovic wrote:
> On 4/5/07, Darren Dale <dd...@co...> wrote:
> > I considered this when setuptools became a requirement for python-2.3
> > installs, but decided against it. My reasoning was that the unfamiliar
> > user would go to install matplotlib, and see setup.py and ez_setup and
> > get confused. Maybe it should go in a subdirectory in our tree?
>
> Just to clear things up, in case there's some misunderstanding:
> ez_setup would be a dir in both cases. You are suggesting that the
> ez_setup dir should be put somewhere other than in the current
> matplotlib toplevel dir (where 'setup.py' resides). Am I correct? 
Sorry, there is some confusion, probably on my part. I was thinking of the 
ez_setup.py file, which suggests that you can run it to install it, or drop 
it in your distribution next to setup.py, either way would be sufficient. I 
though it would be a bad idea to have a setup.py and an ez_setup.py in the 
same directory. We would get people running ez_setup.py and then writing the 
lists asking why they cant import pylab.
Darren

On 4/5/07, Darren Dale <dd...@co...> wrote:
> I considered this when setuptools became a requirement for python-2.3
> installs, but decided against it. My reasoning was that the unfamiliar user
> would go to install matplotlib, and see setup.py and ez_setup and get
> confused. Maybe it should go in a subdirectory in our tree?
Just to clear things up, in case there's some misunderstanding:
ez_setup would be a dir in both cases. You are suggesting that the
ez_setup dir should be put somewhere other than in the current
matplotlib toplevel dir (where 'setup.py' resides). Am I correct? If
so, I don't see why would anyone be confused by having an ez_setup dir
at the top level, but that's just my opinion. In fact, I think that
some of the current dirs at toplevel are more confusing ;). Anyway,
either way (toplevel or subdir) is fine for me.
ez_setup dir will be there only to aid a person that's *building from
source* (normaly a dev building from SVN), so he can allways have the
latest setuptools installed on *his* system.
A person (regular user) that doesn't have setuptools installed, and
just wants to do a "easy_install matplotlib" will still have to
download the ez_setup.py script from
http://peak.telecommunity.com/dist/ez_setup.py , and run it, before
installing matplotlib. Then, he'll soon get into the problem of not
having the appropriate backend installed, but that's another problem
:)
Cheers,
Edin

On Thursday 05 April 2007 4:29:00 am Edin Salkovic wrote:
> On 3/3/07, John Hunter <jd...@gm...> wrote:
> > On 2/23/07, Andrew Straw <str...@as...> wrote:
> > I figured I would be a good crash test dummy to see how easy
> > it was to install setuptools, so I poked around and found the ez_setup
> > and am off to the races. I added a friendly exception to setup.py to
> > make it easier for the next guy
> >
> > if major==2 and minor1<=3:
> > # setuptools monkeypatches distutils.core.Distribution to support
> > # package_data
> > try: import setuptools
> > except ImportError:
> > raise SystemExit("""\
> > matplotlib requires setuptools for installation. Please download
> > http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
> > you are doing a system wide install) to install the proper version of
> > setuptools for your system""")
>
> Apparently, there's a better solution for the above code (source
> http://peak.telecommunity.com/doc/ez_setup/index.html):
> ===
> This directory (svn://svn.eby-sarna.com/svnroot/ez_setup) exists so
> that Subversion-based projects can share a single
> copy of the ``ez_setup`` bootstrap module for ``setuptools``, and have it
> automatically updated in their projects when ``setuptools`` is updated.
>
> For your convenience, you may use the following svn:externals definition::
>
> ez_setup svn://svn.eby-sarna.com/svnroot/ez_setup
>
> You can set this by executing this command in your project directory::
>
> svn propedit svn:externals .
>
> And then adding the line shown above to the file that comes up for editing.
> Then, whenever you update your project, ``ez_setup`` will be updated as
> well. ===
>
> We should then add the following lines to our setup.py script
>
> from ez_setup import use_setuptools
> use_setuptools()
> from setuptools import setup, find_packages
>
> This would make installing setuptools even easier, since the newest
> ez_setup/seuptools would be downloaded by the user/developer every
> time a "svn update;python setup.py install" is issued.
>
> Are the above changes OK?
I considered this when setuptools became a requirement for python-2.3 
installs, but decided against it. My reasoning was that the unfamiliar user 
would go to install matplotlib, and see setup.py and ez_setup and get 
confused. Maybe it should go in a subdirectory in our tree?

On 4/5/07, Bill Baxter <wb...@gm...> wrote:
> So I suggest instead 'npy'. It is already used extensively in the C
> API of Numpy so it has strong precedent as an abbreviation. It also
> *looks* to me like an abbreviation for 'numpy' as opposed to "number
> of points (np)" or something else. Having 3 letters also makes it
> slightly less likely to clash with typical short user variable names.
+1 for npy.

On 3/3/07, John Hunter <jd...@gm...> wrote:
> On 2/23/07, Andrew Straw <str...@as...> wrote:
> I figured I would be a good crash test dummy to see how easy
> it was to install setuptools, so I poked around and found the ez_setup
> and am off to the races. I added a friendly exception to setup.py to
> make it easier for the next guy
>
> if major==2 and minor1<=3:
> # setuptools monkeypatches distutils.core.Distribution to support
> # package_data
> try: import setuptools
> except ImportError:
> raise SystemExit("""\
> matplotlib requires setuptools for installation. Please download
> http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
> you are doing a system wide install) to install the proper version of
> setuptools for your system""")
Apparently, there's a better solution for the above code (source
http://peak.telecommunity.com/doc/ez_setup/index.html):
===
This directory (svn://svn.eby-sarna.com/svnroot/ez_setup) exists so
that Subversion-based projects can share a single
copy of the ``ez_setup`` bootstrap module for ``setuptools``, and have it
automatically updated in their projects when ``setuptools`` is updated.
For your convenience, you may use the following svn:externals definition::
 ez_setup svn://svn.eby-sarna.com/svnroot/ez_setup
You can set this by executing this command in your project directory::
 svn propedit svn:externals .
And then adding the line shown above to the file that comes up for editing.
Then, whenever you update your project, ``ez_setup`` will be updated as well.
===
We should then add the following lines to our setup.py script
from ez_setup import use_setuptools
use_setuptools()
from setuptools import setup, find_packages
This would make installing setuptools even easier, since the newest
ez_setup/seuptools would be downloaded by the user/developer every
time a "svn update;python setup.py install" is issued.
Are the above changes OK?

On 4/4/07, Eric Firing <ef...@ha...> wrote:
> If you want to make one more release, I would like to have a few days
> notice to see if I can clear up at least one thing, and maybe a couple more.
OK, let's shoot for a release next week or the week after, however
long it takes for people to get their current work into svn, tested
and stable, and (optionally) include a deprecation warning for Numeric
and numarray users. The we can get started with the numpy migration
in svn, with the view that we can take our time with it, and try and
get something out in six weeks or so. By that time, Perry and crew
will be almost ready to push out their numpy based release and their
users will be minimally inconvenienced, if at all.
JDH

On 4/5/07, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
> [...]
> > As for your specific points:
> >
> > * inside matplotlib we should just use numpy everywhere. We need to
> > agree on some import convention. I'm happy with 'import numpy as nx'
> > though this might be confusing for a while since people might confuse
> > it with the numerix layer. I like nx because numpy is too long, and N
> > occurs too frequently in regular code. I don't like capital
> > letters.... I could see ns too, since that is what we have been using
> > for the numpy extensions when numpy was originally discussed in the
> > context of the scipy core.
>
> ns is not very mnemonic, and I think we should avoid the confusion
> between nx as numerix and nx as numpy, so I suggest "np" for numpy. It
> is mnemonic, and it will make it easier to keep track of the conversion
> process. An alternative would be "nu".
My opinion is that all of N,np,nu,ns,nx look too much like variable
names I commonly use (nx == number of x values, etc). And none of
them looks particularly to me like the name of a big package for doing
numerical work.
So I suggest instead 'npy'. It is already used extensively in the C
API of Numpy so it has strong precedent as an abbreviation. It also
*looks* to me like an abbreviation for 'numpy' as opposed to "number
of points (np)" or something else. Having 3 letters also makes it
slightly less likely to clash with typical short user variable names.
One thing it doesn't have is a nice analogous abbreviation for scipy.
The direct analog would of course be 'spy', but that's obviously out.
Even if pylab.spy didn't exist, it still doesn't look like an
abbreviation for scipy. I guess I like sci for scipy. npy and sci.
--bb

John Hunter wrote:
> * I suppose we should deprecate it for a release, but I'm inclined
> just to push the thing through quickly
+1
You can't do it too fast for me.
 >* when we do the cleanup, we should replace all the 'from numerix
 >import something' with 'import numpy as nx; nx.something'
+1
 > Where possible when cleaning a given module for numerix, we should
 > standardize the other imports. Eg, instead of 'from cbook import
 > iterable' we should do 'import matplotlib.cbook as cbook;
 > cbook.iterable'
+1
all around a good plan.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

John Hunter wrote:
[...]
> As for your specific points:
> 
> * inside matplotlib we should just use numpy everywhere. We need to
> agree on some import convention. I'm happy with 'import numpy as nx'
> though this might be confusing for a while since people might confuse
> it with the numerix layer. I like nx because numpy is too long, and N
> occurs too frequently in regular code. I don't like capital
> letters.... I could see ns too, since that is what we have been using
> for the numpy extensions when numpy was originally discussed in the
> context of the scipy core.
ns is not very mnemonic, and I think we should avoid the confusion 
between nx as numerix and nx as numpy, so I suggest "np" for numpy. It 
is mnemonic, and it will make it easier to keep track of the conversion 
process. An alternative would be "nu".
> 
> * I suppose we should deprecate it for a release, but I'm inclined
> just to push the thing through quickly because it is a big change and
> if and when we have energy for it we should just get it done. I'm
> also happy to have some sense talked into me. I suppose one
I won't be the one to talk sense into you! This change is going to take 
a some time, and I would like to be able to get started on it. It 
doesn't have to be done all at once.
> possibility is to deprecate it *now* and push out 0.91 ASAP and then
> immediately pull the old support out. I'll post on user's list to get
If you want to make one more release, I would like to have a few days 
notice to see if I can clear up at least one thing, and maybe a couple more.
> a sense of how many people both need the latest mpl and the older
> array packages. I can't imagine there are too many... I'm sure some
> people need Numeric or numarray, but if they are that curmudgeonly,
> surely they can live on the older mpl branch.
[...]
Eric

On Apr 4, 2007, at 9:41 AM, John Hunter wrote:
> On 4/4/07, Andrew Straw <str...@as...> wrote:
>
>> Do we add deprecation warnings for the 0.90+1 release cycle and then
>> stop building the numarray and numeric numerix backends at some point
>> after that? When? Do we keep the "numerix" name or just switch
>> everything to numpy?
>
> I agree that it is about time to begin preparing for the switch. I
> was talking to Perry the other day about what an irony it was for him
> when he was writing the colormap support in mpl that he had to use all
> the takes and puts after spending so much effort in numarray to get
> more natural indexing and other features. So I think most everyone is
> ready to jettison the old stuff and move forward with the new. I've
> been waiting for the green light from STScI that they are mostly
> finished with their numarray->numpy migration since they have made
> significant contributions to mpl (and numerix) and if I recall
> correctly, I think Perry said they were mostly done, which means we
> should go forward. Perry?
We are done internally for all our released software and have 
propagated these changes to our internal users (just this week as a 
matter of fact). The most convenient time to remove the support for 
numarray for us is when we make a public release of our software. The 
date isn't fixed yet but that would probably be in June sometime. The 
reason it is convenient for us to retain the numarray compatibility 
until then is that we release a bunch of things together that people 
can get as one download; taking numarray support out of mpl before 
then means that people with the existing release will have to install 
numpy if they want to upgrade mpl (and also face some confusion about 
what kind of array object they are dealing with if they use functions 
within mpl that create arrays).
Having said that, I've told John that I hate having held up the date 
that the transition to pure numpy in mpl can be accomplished by, and 
that if he wants to he can go ahead with it. So far he has been very 
kind in waiting for us to finish our transition to numpy. So to 
summarize on our end, the conversion to numpy has been completed and 
tested by our developers, and now is being tested by our 
institutional users, and sometime around June we will release our new 
software. At that point, we have no desire or need to have any 
further numarray option in mpl. I'll leave it to John to decide if he 
wants to go ahead with that conversion in mpl now. The effect on our 
user community probably isn't going to be great. By the time it is 
done in mpl and is available to our community there should only be a 
couple months, at most, where our users will have to deal with the 
issue (and they can either wait to upgrade mpl after we release, or 
deal with the installation/array issues that arise for the relatively 
short duration.
Perry

On 4/4/07, Andrew Straw <str...@as...> wrote:
> Do we add deprecation warnings for the 0.90+1 release cycle and then
> stop building the numarray and numeric numerix backends at some point
> after that? When? Do we keep the "numerix" name or just switch
> everything to numpy?
I agree that it is about time to begin preparing for the switch. I
was talking to Perry the other day about what an irony it was for him
when he was writing the colormap support in mpl that he had to use all
the takes and puts after spending so much effort in numarray to get
more natural indexing and other features. So I think most everyone is
ready to jettison the old stuff and move forward with the new. I've
been waiting for the green light from STScI that they are mostly
finished with their numarray->numpy migration since they have made
significant contributions to mpl (and numerix) and if I recall
correctly, I think Perry said they were mostly done, which means we
should go forward. Perry?
As for your specific points:
 * inside matplotlib we should just use numpy everywhere. We need to
agree on some import convention. I'm happy with 'import numpy as nx'
though this might be confusing for a while since people might confuse
it with the numerix layer. I like nx because numpy is too long, and N
occurs too frequently in regular code. I don't like capital
letters.... I could see ns too, since that is what we have been using
for the numpy extensions when numpy was originally discussed in the
context of the scipy core.
 * I suppose we should deprecate it for a release, but I'm inclined
just to push the thing through quickly because it is a big change and
if and when we have energy for it we should just get it done. I'm
also happy to have some sense talked into me. I suppose one
possibility is to deprecate it *now* and push out 0.91 ASAP and then
immediately pull the old support out. I'll post on user's list to get
a sense of how many people both need the latest mpl and the older
array packages. I can't imagine there are too many... I'm sure some
people need Numeric or numarray, but if they are that curmudgeonly,
surely they can live on the older mpl branch.
 * I would like to see the numerix layer live on, not for use in mpl
but for use outside it for folks who have written a lot of code around
it in external scripts. So people who have done
 from pylab import nx
or
 import matplotlib.numerix as nx
will still have working code. Of course we will lose all the mpl
extensions compiled against the other array packages, but with the
array interface I don't think this will pose a problem for people
using mpl with recent versions of Numeric or numarray
 * when we do the cleanup, we should replace all the 'from numerix
import something' with 'import numpy as nx; nx.something' as above.
Where possible when cleaning a given module for numerix, we should
standardize the other imports. Eg, instead of 'from cbook import
iterable' we should do 'import matplotlib.cbook as cbook;
cbook.iterable' Let's use this convention where we use absolute
imports renamed to relative imports, and qualify all module functions
in the code with the module names.
Anything else?
JDH

I think David Cournapeau's email to the -user list (included below) 
brings up the general issue of whether and how and when we want to go 
about deprecating the use of Numeric and numarray in MPL. Their 
continued inclusion in the core of MPL increases complexity (thereby 
slowing development and making bugs more likely) and limits features by 
introducing a least-common-denominator situation. For example, Eric 
Firing and I recently fixed a bug involving masked arrays being passed 
to quiver() that illustrated this issue. I think it's obvious that 
Travis Oliphant is succeeding (or is that "has succeeded"?) in creating 
the definitive array package for Python and people are crazy if they 
write new code with the older packages. That said, I'm sure there's lots 
of old code not yet ported, but numpy has pretty good (copy-less) 
support for Numeric and numarray arrays, too -- just because they won't 
be in the core of MPL doesn't mean they can't be used.
So, this email is just to ask the questions, not to actually propose 
anything concrete:
Do we add deprecation warnings for the 0.90+1 release cycle and then 
stop building the numarray and numeric numerix backends at some point 
after that? When? Do we keep the "numerix" name or just switch 
everything to numpy?
-Andrew
David Cournapeau wrote:
> Hi there,
>
> A few months back, I complained about the slowness of the image 
> function in matplotlib. One of the cullprit was a slow clip function; 
> I've done a bit some work to improve the situation on numpy's side, 
> efforts which were integrated in numpy 1.0.2. Now, when you clip a numpy 
> array with scalar min and max values, you get a 5 to 30 fold speed-up; 
> to get the maximum efficiency, you need inplace clipping (using the 
> syntax a.clip(min, max, a) for a a numpy array). This makes image 
> significantly faster (between 100 and 200 ms on recent computers), and I 
> am sure in other functionalities of matplotlib as well.
> cheers,
>
> David
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Sorry to bug you about this again.
This is an old problem that hasn't been fixed yet.
I don't know how to fix it, but I hope somebody does.
Using Tkinter, in interactive mode, using pylab, after saving by clicking on
the save button on Toolbar2, any reference to the figure will have
disappeared (although the figure window remains open). So the next plot
command will create an entirely new figure.
This bug was started, we think, when we switched to the *much* nicer
filedialog that we are using right now. I would like to keep using the nicer
filedialog, but I also would like the bug to be fixed.
Anybody any ideas?
Thanks, Mark