matplotlib-users Mailing List for matplotlib (Page 1381)

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:

    Hans> I didn't make myself very clear, or I have misunderstood the
    Hans> meaning of "interactive". I presumed that 'interactive'
    Hans> means: I issue the plot command and the figure pops up
    Hans> immediatly, etc.

    Hans> Not interactive (in my understanding) means that I issue all
    Hans> the matplotlib commands I'd like to use and at the end I can
    Hans> use show() to display the picture.

This partially but not completely correct, but it is admittedly
confusing.  Make sure you have read
http://matplotlib.sourceforge.net/interactive.html and
http://matplotlib.sourceforge.net/faq.html#SHOW .  As emphasized in
the FAQ

  IMPORTANT: show should called at most once per script and it should
  be the last line of your script. At that point, the GUI takes
  control of the interpreter. If you want to force a figure draw, use
  draw instead.

If you are issuing plot commands from idle, you need interactive :
True, you should not use show, and if you want finer control of when
the plot pops up and it drawn, use the commands ion, ioff and draw, as
explained on the interactive.html link.

Hope this helps -- if you still encounter problems please let us know
because it is always possible there is a bug ....

JDH

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

    Humufr>        Hi John, I saw that you add in the load function
    Humufr> the possibility to have some line comment with the
    Humufr> character '%'. I would like to change this function and
    Humufr> generalize a little bit this. Not everyone is using the
    Humufr> character '%' but some other like '#' or '!'. So I add
    Humufr> this possibilty to the function. I don't know if you are
    Humufr> agree with it but in case I join the change below.

OK, that's a good idea.  I added it to pylab.py.  In the future,
please add changes to the docstring as well when you change the
function, so that folks who do help(load) will get some information on
what the comments kwarg does.  Thanks...

    Humufr> Another things, I think there are a small bug for the
    Humufr> Tkagg backend. When I close the windows instead to come
    Humufr> back to my shell I'm arriving in a python shell. I tried
    Humufr> (when I had my laptop) with the Gtkagg backend and I
    Humufr> didn't notice this problem.

Not technically a bug, as it was intentional, but perhaps an
annoyance.  In order for python to work with idle, we need this line     

  os.environ['PYTHONINSPECT'] = '1'

in the show function of backends/backend_tkagg.py.  If you comment out
this line the shell will not be raised. 

Todd, any objection to making this an rc parameter, so that people can
optionally have this feature?  Something like

tk.window_focus   : False    # Maintain shell focus for TkAgg
tk.pythoninspect  : False    # True for interactive idle

JSH

John,

>>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
>
>    Hans> Hm. Have upgraded to 0.71. Now I don't get the error message
>    Hans> anymore, however, once I close the figure window, the IDLE
>    Hans> (-n) prompt doesn't respond anymore. (Same scenario as
>    Hans> described in last email.)
>
>    Hans> Ideas?
> Well, if you are using matplotlib interactively from within IDLE< then
> interactive : True should be set in your rc file, no?

I didn't make myself very clear, or I have misunderstood the meaning of 
"interactive". I presumed that 'interactive' means: I issue the plot 
command and the figure pops up immediatly, etc.

Not interactive (in my understanding) means that I issue all the 
matplotlib commands I'd like to use and at the end I can use show() to 
display the picture.

I presumed that when I close the figure windows (by clicking on the right 
symbol on the window), I could carry on using the IDLE session (in this 
example).

Here is the bit that I didn't expect and assumed would be some kind of 
bug:

I need to kill IDLE (when clicking on the [X] symbol in the upper right 
hand corner of the IDLE -n window in MS XP, I get the message :" The 
program is still running! Do you want to kill it?"). In summary, I can't 
carry on using the session once I have used the show() command.

Thanks,

Hans

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:

    Hans> Hm. Have upgraded to 0.71. Now I don't get the error message
    Hans> anymore, however, once I close the figure window, the IDLE
    Hans> (-n) prompt doesn't respond anymore. (Same scenario as
    Hans> described in last email.)

    Hans> Ideas?
Well, if you are using matplotlib interactively from within IDLE< then
interactive : True should be set in your rc file, no?

JDH

Hi John,

>    Hans> The figure windows is interacting (despite the error
>    Hans> message). Once I close the figure window, I can't get back
>    Hans> to the Python prompt; i.e. the shell doesn't respond any
>    Hans> more.
>
>    Hans> Do we expect matplotlib (0.70.1) to work in non-interactive
>    Hans> mode with "IDLE -n"?
>
> This is an unrelated bug fixed in 0.71.
>
> Thanks for the report!

Hm. Have upgraded to 0.71. Now I don't get the error message anymore, 
however, once I close the figure window, the IDLE (-n) prompt doesn't 
respond anymore. (Same scenario as described in last email.)

Ideas?


> JDH
>
>
>
>
>
>
>
>

-------------------------------------------------
Dr Hans Fangohr

Computational Engineering & Design Research Group
School of Engineering Sciences
University of Southampton
Southampton, SO17 1BJ
United Kingdom

Location: Building 25, Room 1027
phone : +44 (0) 23 8059 8345
fax   : +44 (0) 23 8059 7082
email : fa...@so...
-------------------------------------------------

       Hi John,

I saw that you add in the load function the possibility to have some 
line comment with the character '%'. I would like to change this 
function and generalize a little bit this. Not everyone is using the 
character '%' but some other like '#' or '!'. So I add this possibilty 
to the function. I don't know if you are agree with it but in case I 
join the change below.
Another things, I think there are a small bug for the Tkagg backend. 
When I close the windows instead to come back to my shell I'm arriving 
in a python shell. I tried (when I had my laptop) with the Gtkagg 
backend and I didn't notice this problem.

Thanks.

    Nicolas



def load(fname,comments='%'):
    """
    Load ASCII data from fname into an array and return the array.

    The data must be regular, same number of values in every row

    fname can be a filename or a file handle

    matfile data is not currently supported, but see
    Nigel Wade's matfile ftp://ion.le.ac.uk/matfile/matfile.tar.gz

    Example usage:

    x,y = load('test.dat')  # data in two columns

    X = load('test.dat')    # a matrix of data

    x = load('test.dat')    # a single column of data

    """

    if is_string_like(fname):
        fh = file(fname)
    elif hasattr(fname, 'seek'):
        fh = fname
    else:
        raise ValueError('fname must be a string or file handle')
   
    X = []
    numCols = None
    for line in fh:
        line = line[:line.find(comments)].strip()
        if not len(line): continue
        row = [float(val) for val in line.split()]
        thisLen = len(row)
        if numCols is not None and thisLen != numCols:
            raise ValueError('All rows must have the same number of 
columns')
        X.append(row)

    X = array(X)
    r,c = X.shape
    if r==1 or c==1:
        X.shape = max([r,c]),
    return X

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:

    Hans> The figure windows is interacting (despite the error
    Hans> message). Once I close the figure window, I can't get back
    Hans> to the Python prompt; i.e. the shell doesn't respond any
    Hans> more.

    Hans> Do we expect matplotlib (0.70.1) to work in non-interactive
    Hans> mode with "IDLE -n"?

This is an unrelated bug fixed in 0.71.

Thanks for the report!
JDH

Hi John,

I am coming back to our earlier discussion ...

>>>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
>> 
>>> Hm. Done that. A figure window pops up immediately but is
>>> not being updated correctly: a part of the graph is visible,
>>> the other part of the figure (which was underneath another
>>> window initially) appears white. The titel of the figure
>>> says "Figure 1 (Not responding)".  IDLE, however, responds
>>> happily ;-) T
>> 
>> Todd, many moons ago you wrote me and said I had inadvertently screwed
>> up something in tkagg show that broke the idle -n behavior.  If I
>> recall correctly, we never reverted, since I didn't understand exactly
>> what to do.  Perhaps you could revisit the current tkagg versus the
>> old one to make sure it is right.
>> 
>> Hans, does it make a difference if you uncomment
>> 
>> #os.environ['PYTHONINSPECT'] = '1'
>> 
>> in the show method of
>> site-packages/matplotlib/backends/backend_tkagg.py? You should set
>> 'interactive : True' as Todd suggested.  Do not use show, as it is not
>> designed for interactive use.  I suggest carefully testing all 4
>> combinations: with and without the PYTHONINSPECTmline, and with and
>> without -n.
>
> Setting 'interactive=True' in .matplotlibrc
>
> IDLE           #os.environ['PYTHONINSPECT'] = '1'        -> fail
> IDLE -n        #os.environ['PYTHONINSPECT'] = '1'        -> fail
> IDLE           os.environ['PYTHONINSPECT'] = '1'         -> fail
> IDLE -n        os.environ['PYTHONINSPECT'] = '1'         -> success
>
> So that's good.

This doesn't work in non-interactive mode. What I observe is this:

- start Idle with -n (the "==== No Subprocess ====" message appears).
- at prompt issue commands:
>>>import pylab
>>>pylab.plot(range(10))
>>>pylab.show()
- figure windows shows up
- python reports this error message:

>>> pylab.show()
Exception in Tkinter callback
Traceback (most recent call last):
   File "C:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__
     return self.func(*args)
   File 
"C:\Python23\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 215, in key_release
     FigureCanvasBase.key_release_event(self, key)
   File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py",
line 677, in key_release_event
     event = KeyEvent('key_release_event', self, key, self._lastx, 
self._lasty)
   File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py",
line 640, in __init__
     LocationEvent.__init__(self, name, canvas, x, y)
   File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py",
line 566, in __init__
     if a.in_axes(self.x, self.y):
   File "C:\Python23\Lib\site-packages\matplotlib\axes.py", line 1544, in 
in_axes
     return self.bbox.contains(xwin, ywin)
TypeError: float() argument must be a string or a number


The figure windows is interacting (despite the error message). Once I 
close the figure window, I can't get back to the Python prompt; i.e. the 
shell doesn't respond any more.

Do we expect matplotlib (0.70.1) to work in non-interactive mode with 
"IDLE -n"?

Thanks,

Hans

As a protanope, and knowing that lots of folks with interest in graphics 
frequent this newsgroup, I thought I'd call everyone's attention to the 
article entitled "The End of the Rainbow? Color Schemes for Improved 
Data Graphics" which appeared in the 5 October 2004 issue of the 
American Geophysical Union's weekly newsmagazine EOS.  A Web site with 
the sample color schemes and a copy of the article is at 
http://geography.uoregon.edu/datagraphics/

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