matplotlib-users Mailing List for matplotlib (Page 3)

On Jan 24, 2005, at 10:09 AM, John Hunter wrote:
> So the two questions are: 1) are people in favor of this change? and

I haven't given lengthy thought, but yes, I think it is probably a good
idea. The only counterargument is that something like making them 
available
in pylab is that it guards a bit against possible reorganization of the
modules and could potentially shield users against that. One view of 
pylab
is that it provides a more stable interface to what is underneath. If 
there
are items that are pretty fixed in their design, perhaps they belong 
(here
or in another related module)

> 2) if so, what should matplotlib.pylab export?  Only symbols defined
> therein?  Or perhaps add a few for backward compatibility?  
> Specifically
> I'm wondering if matplotlib.pylab should continue to export: cm.jet,
> cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and
> *Formatter symbols from matplotlib.ticker and matplotlib.dates?  I
> don't suppose it's possible to "warn on import", eg warning
> "matplotlib.pylab import of date2num is deprecated, please use
> matplotlib.dates instead".  One could write wrappers for this, I know,
> but is there some import wizardry which supports this?
>
I think one could overload the import mechanism to handle this, but I'm
thinking that it is probably not worth the downside of messing with
the import mechanism.

Perry

Hi folks, I've noticed that zooming on the text won't make the text any 
larger, and some other instances like sub-axes share the problem too. And it 
is not the default zoom behavior people usually expect. Any solution to 
that?

Bao 

Hi a quick question:

- how do I write a label like this:

ylabel("$\sigma_{\rm{R}} / \sigma_e$")

to have: sigma_R / sigma_e with the R in \rm mode ?

At the moment it does not seem to work..

thanks for any help there.

[Is there any exhaustive list of what we can do in latex-like mode ?
I am for example looking for different ways to include ''spaces'']

Eric

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

Am Montag, 24. Januar 2005 16:09 schrieb John Hunter:
> >>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
>
>     Norbert> What about pulling all the plotting routines into a
>     Norbert> separate file that can be included by anyone who just
>     Norbert> wants the comfortable plotting commands without all the
>     Norbert> other namespace cluttering. pylab itself would then only
>     Norbert> contain lots of imports and all the namespace mangling.
>
> I think this is a good idea, especially since is a natural way to do
> it with the existing organization that shouldn't break much code.  We
> already have the two modules in place: matplotlib.pylab and pylab.
> The former would just export the plotting symbols defined therein and
> the latter would be the namespace aggregator.

Don't know, whether it is a good idea to make a distinction between pylab and 
matplotlib.pylab - It would be clearer to create a new module (maybe 
matplotlib.plotting, matplotlib.pyplot or whatever) and move all routines 
from pylab to that new module.

That would make clear: the term 'pylab' stands for the idea to create an 
environment that is as similar as possible to matlab.

For the question what the new module should contain: only a small, clear-cut 
set of routines. A regular module should only export what it defines itself. 
Re-exporting blurs the modularity of the library and makes it harder to 
understand.

Ciao,
Norbert

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> What about pulling all the plotting routines into a
    Norbert> separate file that can be included by anyone who just
    Norbert> wants the comfortable plotting commands without all the
    Norbert> other namespace cluttering. pylab itself would then only
    Norbert> contain lots of imports and all the namespace mangling.

I think this is a good idea, especially since is a natural way to do
it with the existing organization that shouldn't break much code.  We
already have the two modules in place: matplotlib.pylab and pylab.
The former would just export the plotting symbols defined therein and
the latter would be the namespace aggregator.  Thus pylab.__all__
would be just as it is with 0.71 (plotting, numerix, mlab,
matplotlib.dates symbols, matplotlib.ticker symbols, some colormapping
stuff) and matplotlib.pylab.__all__ would only be the plotting
commands.

Scripts which currently do 

  from pylab import *
 
would be unaffected.

There are some scripts which would be affected by these changes for
those who eschew 'import *'.  If you are getting the DateFormatter
from pylab, you'll have to get it from matplotlib.dates instead.
Basically, this would primarily affect people who are using custom
tick locators or date locators/formatters.  Of course,
matplotlib.pylab *could* continue to provide these, but that seems to
defeat the purpose of the change, which is to be more rigorous about
exported namespaces.

So the two questions are: 1) are people in favor of this change? and
2) if so, what should matplotlib.pylab export?  Only symbols defined
therein?  Or perhaps add a few for backward compatibility?  Specifically
I'm wondering if matplotlib.pylab should continue to export: cm.jet,
cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and
*Formatter symbols from matplotlib.ticker and matplotlib.dates?  I
don't suppose it's possible to "warn on import", eg warning
"matplotlib.pylab import of date2num is deprecated, please use
matplotlib.dates instead".  One could write wrappers for this, I know,
but is there some import wizardry which supports this?  

JDH

Hello John,

On Thu, Jan 20, 2005 at 02:07:26PM -0600, John Hunter wrote:
>     p =3D Rectangle((1,1),3,3,fill=3DFalse)
>     ax.add_patch(p)
>=20
> your rectangle is in *data coordinates* and it is where it should be
> (center at 1,1 and width=3Dheight=3D3).

I think this is wrong.  The lower-left corner is at (1,1), not
the center.  At least help(Rectangle) states

 |  __init__(self, xy, width, height, **kwargs)
 |      xy is an x,y tuple lower, left
 |     =20
 |      width and height are width and height of rectangle
 |     =20
 |      fill is a boolean indicating whether to fill the rectangle

All the best,
Jochen
--=20
http://seehuhn.de/

John Hunter wrote:

>>>>>>"Stephen" == Stephen Walton <ste...@cs...> writes:
>>>>>>            
>>>>>>
>
>    Stephen> I need a function which will take an N by 3 or N by 6
>    Stephen> array... and convert them to matplotlib
>    Stephen> dates.  
>  
>

>    from datetime import datetime
>    from pylab import date2num
>    x = ...your array
>    dts = date2num([ datetime(y,m,d) for y,m,d in x ])
>
>  
>
This works fine, John, as do your other ideas as well.

>FYI, date2num is found in matplotlib.dates.  I'll take a look at the
>matlab datenum docstring in matlab and see about including this
>functionality in the matplotlib.dates version.
>  
>
No need.  The functionality is already there and I need to begin 
"thinking in Python."  Using tuple unpacking on rows of an array did not 
occur to me, I admit.

Steve

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen> I need a function which will take an N by 3 or N by 6
    Stephen> array, where the columns are year, month, day in the
    Stephen> first case and those three plus hours, minutes, and
    Stephen> seconds in the second case and convert them to matplotlib
    Stephen> dates.  This would work the same as the MATLAB datenum()
    Stephen> function.

Hi Stephen,

How about

    from datetime import datetime
    from pylab import date2num
    x = ...your array
    dts = date2num([ datetime(y,m,d) for y,m,d in x ])

or for the Nx6 case

    dts = date2num([ datetime(y,m,d,h,min,s) for y,m,d,h,min,s in x ])

or more succinctly

    dts = date2num([ datetime(*date) for date in x ])

FYI, date2num is found in matplotlib.dates.  I'll take a look at the
matlab datenum docstring in matlab and see about including this
functionality in the matplotlib.dates version.

Cheers,
JDH

I need a function which will take an N by 3 or N by 6 array, where the 
columns are year, month, day in the first case and those three plus 
hours, minutes, and seconds in the second case and convert them to 
matplotlib dates.  This would work the same as the MATLAB datenum() 
function.

Thanks in advance.

Maybe, the situation could be somewhat relaxed by uncluttering pylab:

Currently, pylab.py does two things:

* give a stateful matlab like interface to the object-oriented matplotlib 
plotting library

* pull together all kinds of namespaces.

What about pulling all the plotting routines into a separate file that can be 
included by anyone who just wants the comfortable plotting commands without 
all the other namespace cluttering. pylab itself would then only contain lots 
of imports and all the namespace mangling.

For me personally, this would be the solution. I use matplotlib for plotting 
only and for my purpose , simple plotting interface from pylab is much nicer 
than the full object oriented interface.

For numerics, however, I would prefer to go as pythonic as possible without 
any compromises for matlab similarity.

Cleanly dividing the two purposes of matplotlib (nice plotting and matlab 
similarity) would certainly help matters.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

>>>>> "danny" == danny shevitz <dan...@ya...> writes:

    danny> my comments on modules being exposed appear to have fallen
    danny> into a vacuum. I still ask if "from matplotlib import *"
    danny> should expose the time module or the sys module?

Hi Danny,

Apparently your voice has escaped the void!  I added the __all__
attribute to the pylab module to restrict the symbols it exports
strictly to matplotlib and numerix symbols, which should protect you
from these kids of unexpected effects.

Cheers,
JDH

This matplotlib release will be included in enthought's next release
of enthought python, which is widely used by windows users for
scientific computing.  I'd like to get an stable-as-possible release
in, since enthought python is released very infrequently.  Joe Cooper,
who is handling the release, says we can get fixes in until sometime
on Monday, so I'd be much obliged if you all could stress test this
release in case I need to get a bug-fix in.  There have been some
potentially script breaking substantial changes to the numerix module
described below, so these tests are doubly important.

What's new in matplotlib 0.71

numerix refactor

  The organization of the numerix module was refactored to be mindful
  of namespaces. See http://matplotlib.sf.net/API_CHANGES. pylab no
  longer overrides the built-ins min, max, and sum, and provides amin,
  amax and asum as the numerix/mlab versions of these.  pylab defines
  __all__ to prevent surprises when doing from pylab import *.  To see
  the complete list of symbols provided

    >>> import matplotlib.pylab
    >>> matplotlib.pylab.__all__

contour zigzag bug fixed

  Thanks Nadia for the blood, sweat and tears, and Dominique for the
  report.

contour colormaps

  Contour now uses the current colormap if colors is not provided, and
  works with colorbars.  See examples/contour_demo2.py

colorbar enhancements

  Horizontal colorbars supported with keyword arg
  orientation='horizontal' and colorbars can be placed in an arbitrary
  axes with keyword arg cax.

accents in mathtext

  Added accents to mathtext: \hat, reve, \grave, ar, cute, ilde, ec,
  \dot, \ddot. All of them have the same syntax, eg to make an overbar
  you do ar{o} or to make an o umlaut you do \ddot{o}. The shortcuts
  are also provided, eg: "o 'e \`e \~n \.x \^y . See
  examples/accent_demo.py

fixed super/subscript parsing in mathtext

  Widowed superscripts now work, eg r'$^12 m{CO}$'

little bugs and enhancements

  Plugged some memory leaks in wx and image module, fixed x,y args in
  contour, added latex symbol kappa, fixed a yticklabel problem under
  change in clim, fixed colorbar number of color bug, fixed
  set_clip_on bug, reverted pythoninspect in tkagg, fixed event
  handling bugs, fixed matlab-compatible load function, exposed vbox
  attr in FigureManagerGTK.


I did not get a chance to get the aspect=preserve imshow bugs fixed on
this iteration.  Something for next time!

  http://matplotlib.sourceforge.net

JDH

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:

    Dominique> Results seem inconsistent; if i replace the
    Dominique> 'rosenbrock' function in my previous script with

The bug resulted from improperly initializing an array used in the
contour extension code.  Fortunately Nadia has found and fixed it.
The changes are in CVS (colormaps and colorbars for contour too!) and
will be out in the next release, coming soon to theaters
everywhere.....

JDH

>>>>> "Simon" == Simon Burton <si...@ar...> writes:

    Simon> add/remove methods ? Or is the (recently changed)
    Simon> collections attribute the Right Way (TM) to do this kind of
    Simon> thing ?

Yes, I you're doing it the right way.  I decided to make these
attributes "public" when working on the figures for the "Matplotlib
API" chapter of the users guide, eg Figure 7.4, which shows the Artist
containment hierarchy and the respective attribute names.  

  http://matplotlib.sourceforge.net/users_guide_0.70.pdf

I've historically been reluctant to publicize the API in order to
leave wiggle room for refactoring the internals, but now I'm
reasonably satisfied and the API has been mostly stable for several
releases.  The choice to remove the underscore on these attribute
names was an unheralded decision that the basic API / containment
hierarchy is stable for the foreseeable future.

You can safely use the list remove method w/o breaking anything.  If
you want to manually add an artist to the Axes, you should use the
Axes add_patch, add_line, add_collection, etc, methods rather than the
list append method, unless you really know what you are doing.  These
add_* methods set some default attributes of the artist, eg they call
the set_figure, set_transform, and update the data limits for viewport
autoscaling.  So you either need to use the add_* methods to add
artists or call these methods yourself.

JDH

Hi,

I've been working on a data entry app: the user clicks on a canvas to place scatter plot items.
The app also has an "eraser" to remove points. So, I'm having to get the collections attribute
from the axes, look at offsets, and remove items etc. It all feels like a real hack, eg.
the (older) installed version of matplotlib uses ._collections instead of (the newer) .collections attribute.

Well, I'd like to suggest adding a method or three to the axes class that allows a client
to get/change these items. It doesn't look like it would take much code.

Alternatively, I guess the app could just clear the axes and scatter down the points again, minus the
deleted point. This is not so clever though: as more items are added to the axes (lines/images etc.)
it would get more difficult to manage these. And since the axes already manages these items,
why not expose some kind of list-like add/remove methods ? Or is the (recently changed) collections attribute
the Right Way (TM) to do this kind of thing ?

ciao, (and by the way, I am immensly impressed with the matplotlib code)

Simon.

--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com

Sorry Andrew.  I wasn't paying careful enough attention to what John was
saying and have a different idea of what numerix should evolve into:  a
simple numarray/Numeric switcher which provides "normalized" access to
the standard packages.  If multiple namespaces are combined,  that's OK
as long as we don't inject new behavior which defeats numerix's role as
a Numeric replacement.  In the general sense,  the purpose of numerix is
to make Numeric software available for numarray users.  Fairly soon I
think we're going to want to factor it out of matplotlib and use it in
other places.

I agree with John that numerix is not completely a simple switcher now, 
but I think that's where it needs to head.  Whatever short term solution
is chosen for min,max,etc... isn't that big a deal.

Regards,
Todd

On Thu, 2005-01-20 at 15:41, Andrew Straw wrote:
> OK, let's get this straight.  The situation as it stands:
> 
> Currently in CVS is an implementation such that "from pylab import *" 
> does not override builtins.  I think we all agree that this is the right 
> behavior. The question is now the implementation.  (The code I checked 
> in simply restores of pylab's names to the builtins. e.g. in the 
> pylab.py: "min = __builtin__.min")
> 
> John suggests moving my "solution" (I prefer to think of it as a 
> band-aid, curing the symptom, but not the cause) up the chain to 
> numerix, such that numerix.min = __builtin__.min (same for max, etc). 
> Additionally, he suggests bringing a few more names into existence such 
> that numerix.nxmin = mlab.min (same again for max, etc).  I have no 
> problem with this, but Todd "we should keep numerix compatible with 
> Numeric" Miller does, and I can see he has a valid point.  Thus, I see 
> no easy resolution which is of little consequence to those of us who do 
> not use numerix in our code.
> 
> Since I am personally quite busy with other stuff, and I don't see a 
> clear consensus of this numerix issue, which is secondary to my initial 
> gripe regarding pylab. I am disinclined to do anything more at this 
> point.  I will hereby let someone who cares more than I do about numerix 
> take it from here.
> 
> For the record, I agree with everyone that "from blah import *" is a bad 
> idea. However, pylab is special and thus deserves special attention. 
> Partly this is because John, Fernando, and others have spent many hours 
> making sure it plays well in IPython, resulting in IPython's pylab mode 
> being the best Python interactive scientific plotting solution. 
> Personally, I agree with Fernando's decision to do a "from pylab import 
> *" in ipython -pylab because it enables rapid, interactive data 
> exploration. (Besides which, it freakin' rocks!! :)
> 
> Given ipython -pylab is my most frequently used interactive Python, I 
> want min/max/etc to be the builtin functions (especially since I tend to 
> do "run -i blah.py" from IPython a lot, which thus inherit names, 
> including min and max, from ipython's interactive namespace).
>  
> Also, I am still intrigued by Norbert's suggestion to change Python 
> itself to eliminate this mess, but I don't have the time to deal with 
> it. Furthermore, even if someone did step up to the plate, this is a 
> longer term solution, and we'd still need a "band-aid" for the immediate 
> term.
> 
> Getting back to my day job now,
> Andrew

OK, let's get this straight.  The situation as it stands:

Currently in CVS is an implementation such that "from pylab import *" 
does not override builtins.  I think we all agree that this is the right 
behavior. The question is now the implementation.  (The code I checked 
in simply restores of pylab's names to the builtins. e.g. in the 
pylab.py: "min = __builtin__.min")

John suggests moving my "solution" (I prefer to think of it as a 
band-aid, curing the symptom, but not the cause) up the chain to 
numerix, such that numerix.min = __builtin__.min (same for max, etc). 
Additionally, he suggests bringing a few more names into existence such 
that numerix.nxmin = mlab.min (same again for max, etc).  I have no 
problem with this, but Todd "we should keep numerix compatible with 
Numeric" Miller does, and I can see he has a valid point.  Thus, I see 
no easy resolution which is of little consequence to those of us who do 
not use numerix in our code.

Since I am personally quite busy with other stuff, and I don't see a 
clear consensus of this numerix issue, which is secondary to my initial 
gripe regarding pylab. I am disinclined to do anything more at this 
point.  I will hereby let someone who cares more than I do about numerix 
take it from here.



For the record, I agree with everyone that "from blah import *" is a bad 
idea. However, pylab is special and thus deserves special attention. 
Partly this is because John, Fernando, and others have spent many hours 
making sure it plays well in IPython, resulting in IPython's pylab mode 
being the best Python interactive scientific plotting solution. 
Personally, I agree with Fernando's decision to do a "from pylab import 
*" in ipython -pylab because it enables rapid, interactive data 
exploration. (Besides which, it freakin' rocks!! :)

Given ipython -pylab is my most frequently used interactive Python, I 
want min/max/etc to be the builtin functions (especially since I tend to 
do "run -i blah.py" from IPython a lot, which thus inherit names, 
including min and max, from ipython's interactive namespace).
 
Also, I am still intrigued by Norbert's suggestion to change Python 
itself to eliminate this mess, but I don't have the time to deal with 
it. Furthermore, even if someone did step up to the plate, this is a 
longer term solution, and we'd still need a "band-aid" for the immediate 
term.

Getting back to my day job now,
Andrew

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr> I understand your point but I think that to draw on object
    Humufr> inside a figure, using some relative coordinate are not
    Humufr> very convenient. You add to play with the data coordinates
    Humufr> and the figures coordinates. That can be useful for some
    Humufr> objects but very often some people would like to plot a
    Humufr> rectangle (or what do you want) with the data corrdinate
    Humufr> and it's very disturbing at the beginning the way that
    Humufr> patches is working.  I don't know if I'm clear this time
    Humufr> (my english is very poor sometimes).

Yes, apparently there is something of a language barrier -- my french
is not so good either, sigh.  

But I just want to reiterate, you are not using relative coords for
the rectangle in the example below.  When you do the following,

    from pylab import *
    from matplotlib.patches import Rectangle
    ax = gca()
    p = Rectangle((1,1),3,3,fill=False)
    ax.add_patch(p)

your rectangle is in *data coordinates* and it is where it should be
(center at 1,1 and width=height=3).  The problem is that your axis
"view" limits are not set properly (if you use the pan and zoom
features of the toolbar to move your view limits you'll see the
rectangle where it should be.  Only the plot commands (plot, scatter,
etc,....) call autoscale_view to set the view limits (add_patch does
not), so you need to set the axis limits yourself.

  axis([0,10,0,10])

In summary, the rectangle is being added in the right coordinate
system (data coords) but the view limits are not automatically
autoscaled unless you issue a plot command.  I choose not to do
autoscale every time a patch is added for performance reasons -- if
you are savvy enough to call add_patch, I assume you are savvy enough
to call set_xlim or set_ylim as appropriate for your data.


JDH

John Hunter wrote:

>>>>>>"Humufr" == Humufr  <hu...@ya...> writes:
>>>>>>            
>>>>>>
>
>
>    Humufr> but if you use axis only without redefine gca limit that
>    Humufr> don't work:
>
>    Humufr> from pylab import * from matplotlib.patches import
>    Humufr> Rectangle axis([0,10],[0,10]) ax = gca() p =
>    Humufr> Rectangle((1,1),3,3,fill=False) ax.add_patch(p)
>
>I think you screwed up the "axis" syntax.  What you mean (I think) is:
>
>    from pylab import *
>    from matplotlib.patches import Rectangle
>    axis([0,10,0,10])
>    ax = gca()
>    p = Rectangle((1,1),3,3,fill=False)
>    ax.add_patch(p)
>    show()
>  
>

yes sorry I did mistake in my mail but the result is the same. I can't 
draw the rectangle where I want. To do this I had to set the xlim and 
ylim manually.

>    Humufr> I understand that gca return an instance but perhaps that
>    Humufr> will be a good idea if by default that will use the axis
>    Humufr> of the courrant figure and not [0,1,0,1].
>
>I'm a little confused here.  gca returns the current axes (note axis
>and axes are different commands and have different meanings).  The
>default axes is
>
>2 >>> ax = gca()
> 
>3 >>> ax.get_position()
>Out[3]: [0.125, 0.10999999999999999, 0.77500000000000002, 0.79000000000000004]
>
>Can you clarify your meaning?  axis set the view limits of the current
>axes.  The view limits are in data coordinates, and these are the same
>limits that are controlled by xlim and ylim.  axes sets the position
>of the axes (the frame in which your plots are made) and these
>coordinates are in figure coords -- 0,0 is lower left of the figure
>and 1,1 is upper right.
>  
>

I understand your point but I think that to draw on object inside a 
figure, using some relative coordinate are not very convenient. You add 
to play with the data coordinates and the figures coordinates. That can 
be useful for some objects but very often some people would like to plot 
a rectangle (or what do you want) with the data corrdinate and it's very 
disturbing at the beginning the way that patches is working.
I don't know if I'm clear this time (my english is very poor sometimes).

Thanks,

    Nicolas

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:


    Humufr> but if you use axis only without redefine gca limit that
    Humufr> don't work:

    Humufr> from pylab import * from matplotlib.patches import
    Humufr> Rectangle axis([0,10],[0,10]) ax = gca() p =
    Humufr> Rectangle((1,1),3,3,fill=False) ax.add_patch(p)

I think you screwed up the "axis" syntax.  What you mean (I think) is:

    from pylab import *
    from matplotlib.patches import Rectangle
    axis([0,10,0,10])
    ax = gca()
    p = Rectangle((1,1),3,3,fill=False)
    ax.add_patch(p)
    show()

    Humufr> I understand that gca return an instance but perhaps that
    Humufr> will be a good idea if by default that will use the axis
    Humufr> of the courrant figure and not [0,1,0,1].

I'm a little confused here.  gca returns the current axes (note axis
and axes are different commands and have different meanings).  The
default axes is

2 >>> ax = gca()
 
3 >>> ax.get_position()
Out[3]: [0.125, 0.10999999999999999, 0.77500000000000002, 0.79000000000000004]

Can you clarify your meaning?  axis set the view limits of the current
axes.  The view limits are in data coordinates, and these are the same
limits that are controlled by xlim and ylim.  axes sets the position
of the axes (the frame in which your plots are made) and these
coordinates are in figure coords -- 0,0 is lower left of the figure
and 1,1 is upper right.

JDH

As long as this is being discussed, I'll put in my $0.2

I think encouraging "import *" Is a BAD IDEA. Even for interactive use.

Since I've used Python, the only time I've used import * is for Numeric, 
and now I've started using import Numeric as N.

>  Namespaces are one honking great idea -- let's do more of those!

That's why I'm resistant to using import *

Anyway, I'm very happy about matplotlib because it does most of what I 
need, does it well, works with wx and AGG, and is constantly being improved.

However, even though I'm an old matlab fanatic, I'm not thrilled with 
the efforts to make matplotlib matlab-like. I have various reasons for 
using Python rather than matlab, but one of the primary ones is that I 
like the language better, and I like OO. Hence, I'd much rather have a 
platting package be pythonic than matlab-like. Name spaces and OO are a 
big part of this.

Name spaces and an OO interface are very linked, by the way. The reason 
NumPy is commonly used with the import * approach is that there are a 
LOT of functions exposed, and we all get tired of typing Numeric. (or 
even N.). However, many of those functions should really be methods. 
I've always been confused by the Numeric docs, which suggest that the 
function interface is necessary so that you can do, for instance:

B = Numeric.transpose(A)

and A doesn't have to be a Numeric Array. This would be very cool if 
transpose (and many other ufuncs) returned the type that was input, but 
it doesn't, it returns an array, so it's really the equivalent of:

B = array(A)
B.transpose(B)

if transpose were an array method. Is it really so onerous to type that 
extra line? I like the extra line, because it makes things clear to me 
what's going on.

anyway, to cut my rant short, here is my vote for matplotlib development 
(not that I get a vote, but hopefully I'll have time to help out someday)

1) Deprecate "from pylab import *"
2) Improve the OO interface to make it just as easy to use.

Even with improvements, I understand that it will be a little bit more 
awkward to use in interactive mode, but how much does anyone really do 
interactively anyway? Even with Matlab, I soon learned that if I'm 
typing more that 3 lines, I should put it in a script.

I know we can do (2) without doing (1), but if (1) is what's in all the 
examples, it's going to get used.

OK, enough of my rant.

-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

Chr...@no...

             Hi,
 so I found some answer to the second problem, to draw a rectangle at a 
certain place you add to define  the limit for gca instance, by default 
the limit of the figure are not use:

from pylab import *
from matplotlib.patches import Rectangle
ax = gca()
set(gca(),'xlim',[0,10],'ylim',[0,10])
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)

or more pythonic:

from pylab import *
from matplotlib.patches import Rectangle
ax = gca()
ax.set_xlim([0,10])
ax.set_ylim([0,10])
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)


but if you use axis only without redefine gca limit that don't work:

from pylab import *
from matplotlib.patches import Rectangle
axis([0,10],[0,10])
ax = gca()
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)

I understand that gca return an instance but perhaps that will be a good 
idea if by default that will use the axis of the courrant figure and not 
[0,1,0,1].

Thanks,

          Nicolas

Humufr wrote:

>             Hi,
>
> I have a problem to draw a rectangle:
>
> The first is that I can't arrive to draw a rectangle with ipython 
> -pylab, the script who work when it's launch independantly is not 
> working interactively. The rectangle is not draw. Perhaps it's normal 
> but I don't think.
>
> The second problem I have is to draw a rectangle at a certain position 
> with certain height and width. It's seems (at least when I tried to 
> use it) that the position must be done relatively at the window and 
> not from the plot. It's not very convenient because if I have a plot 
> draw between 1 and 100 in x and y, to draw the rectangle I add to use 
> something between 0 and 1 so I had to rescale the rectangle.
>
> Thanks,
>
>    Nicolas

On Thu, 2005-01-20 at 09:28, John Hunter wrote:
> >>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:
> 
>     Norbert> Why not go one step higher and discuss the issue in
>     Norbert> Numeric and numarray? It seems like a typical problem in
>     Norbert> the python community that conflicts are not discussed and
>     Norbert> decided centrally but instead everyone just does things
>     Norbert> their way. The possibility to change and fix everything
>     Norbert> by a wrapper module really causes a huge mess in the
>     Norbert> various libraries...
> 
> I still believe that this is not a problem with Numeric or numarray
> [1].  There is nothing to fix there in my opinion (Todd or Perry can
> jump in here).  Those modules provide min/max/etc in their respective
> mlab modules, which do exactly what they advertise: they provide
> matlab functionality and matlab provides min/max with a different
> signature than python's. 

I agree with this;  pylab has a very clear "right" to choose whatever
API semantics it wants.  It occurs to me now that numerix probably needs
to evolve away from MLab back to pure Numeric,  but that has nothing to
do with the pylab API which can remain as it is.

I agree that overriding builtins is a mistake,  but I think we're in a
bind here.

[snip]

> There is no problem as long as the user is
> mindful of namespaces; there's a reason your mother always told you
> never to do 'from somemodule import *'.  I tend to heed that advice,

This is my position as well:  Don't use from *.  Using it opens you up
to new names appearing in your module namespace based on changes outside
the module;  using it non-interactively is an engineering error. 

[snip]

> Perhaps I'm wrong, but I suspect that 1) Numeric developers would be
> very reluctant to change a name that has been in the code base for
> god-knows-how-long and thus would break lots of code, and 2) the
> functions in MLab actually do exactly what they are designed to do and
> are well advertised as such.  I for one would definitely be against a
> change, because when I do MLab.min I want the matlab signature.

I have a strong aversion to breaking Numeric compatibility,  so I need
to reverse my earlier "unleash Andrew" comment and we should keep
numerix compatible with Numeric.

[snip]

> MLab versions.  Two different packages/modules can rightly have
> different policies on how closely they want to abide by the matlab
> names.

I agree.  That's why Python has namespaces.

IMHO, this boils down to choosing the lesser of two evils,  so if we're
talking about breaking APIs in the name of purity or remaining
compatible with Numeric but a little impure,  I'd prefer compatible.  My
$.02

Cheers,
Todd

>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:

    Norbert> Why not go one step higher and discuss the issue in
    Norbert> Numeric and numarray? It seems like a typical problem in
    Norbert> the python community that conflicts are not discussed and
    Norbert> decided centrally but instead everyone just does things
    Norbert> their way. The possibility to change and fix everything
    Norbert> by a wrapper module really causes a huge mess in the
    Norbert> various libraries...

I still believe that this is not a problem with Numeric or numarray
[1].  There is nothing to fix there in my opinion (Todd or Perry can
jump in here).  Those modules provide min/max/etc in their respective
mlab modules, which do exactly what they advertise: they provide
matlab functionality and matlab provides min/max with a different
signature than python's.  There is no problem as long as the user is
mindful of namespaces; there's a reason your mother always told you
never to do 'from somemodule import *'.  I tend to heed that advice,
with the one exception being pylab, in which I try to provide a
matlab-like environment where the symbols are all provided in a single
namespace.

Note also that matplotlib's numerix module is more than a simple
numarray/Numeric switcher because it *combines* symbols from all of
their respective submodules.  Eg from na_imports, which is where
matplotlib.numerix gets the numarray symbols from

    from numarray.linear_algebra.mlab import *
    from numarray import *
    import numarray.linear_algebra as LinearAlgebra
    import numarray.linear_algebra.mlab as MLab
    from numarray.linear_algebra import inverse, eigenvectors
    from numarray.convolve import convolve
    from numarray.fft import fft
    import numarray.random_array as RandomArray
    from numarray.numeric import nonzero

So we are taking names from a bunch of different namespaces and
pooling them in numerix, which is then pooled into pylab.  This is a
good thing for users who want a matlab-like environment, and who want
to be able to switch between Numeric and numarray w/o having to write
a bunch of conditional code to handle the different directory layouts,
but as we've observed can bite you if you are unaware that pylab is
providing matlab names rather than python names in some cases.

Perhaps I'm wrong, but I suspect that 1) Numeric developers would be
very reluctant to change a name that has been in the code base for
god-knows-how-long and thus would break lots of code, and 2) the
functions in MLab actually do exactly what they are designed to do and
are well advertised as such.  I for one would definitely be against a
change, because when I do MLab.min I want the matlab signature.

Basically the question is: when confronted with a name clash, should a
module prefer python over matlab.  Numeric.MLab rightly (I think)
chose to go with matlab names, but some disagree with this decision
(yes, you Fernando).  For pylab, which has its genesis in matlab
compatibility but serves a wider community that may not know or care
about matlab, it may be sensible to make a different choice.  In
brief, I don't think it is terribly confusing for Numeric.MLab to have
one policy that when confronting a name clash they go with the matlab
name, and for matplotlib.numerix have a different policy and say we'll
go with the built-in and provide the amin, amax, etc symbols for the
MLab versions.  Two different packages/modules can rightly have
different policies on how closely they want to abide by the matlab
names.

JDH


[1] http://sourceforge.net/mailarchive/message.php?msg_id=10514961

Am Mittwoch, 19. Januar 2005 23:39 schrieb John Hunter:
> I thought we last left this with the idea that these changes would be
> made in matplotlib.numerix level

Why not go one step higher and discuss the issue in Numeric and numarray? It 
seems like a typical problem in the python community that conflicts are not 
discussed and decided centrally but instead everyone just does things their 
way. The possibility to change and fix everything by a wrapper module really 
causes a huge mess in the various libraries...

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>