matplotlib-users Mailing List for matplotlib (Page 6)

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

import pylab as P

Ted

At 10:04 AM 5/18/2005, Derrick Snowden wrote:
>Fernando Perez wrote:
>
>>John Hunter wrote:
>>
>>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes:
>>>
>>>     >> I'm wondering if set is now a bad name for pylab to be using?
>>>
>>>     Tim> +1 for changing it.
>>>
>>>     Tim> I've also had this issue bite me when I was hacking together
>>>     Tim> some code and wanted to use a python set. I'd be in favour of
>>>     Tim> changing the pylab set to be called something else, although
>>>     Tim> I don't have any good suggestions about what to change it
>>>     Tim> to...
>>>
>>>Ouch, I hadn't thought of this.  In the past, consensus has been that
>>>pylab should not override built-ins, eg the previous discussion on
>>>min/max which led us to rename these functions to amin/amax.  Changing
>>>set, unfortunately, will break a lot of scripts.  I think the best
>>>plan of action is to define a new function pset or setp (setp for "set
>>>property") which has the functionality of the old, and keep set around
>>>for a release or two issuing a warning with a line number so people
>>>can get their existing scripts cleaned up.
>>
>>
>>I'd also suggest removing from all example code 'from pylab import *' 
>>statements.  Frankly, after a while I've completely stopped using 'from 
>>foo import *' in _any_ code I write, even small scripts.  All I use these 
>>days is code like:
>>
>>import Numeric as N
>>import scipy as S
>>import pylab as P
>>
>>The only place where I think that from-import-* is OK is at an 
>>interactive prompt, where you are just doing experiments and not writing 
>>reusable code.
>>
>>Since the examples tend to be the place that people learn from, I think 
>>it would be a good idea to encourage safer practices by banning the 
>>dangerous import-* idiom from there.
>>
>>Just my opinion.
>>
>>Best,
>>
>>f
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Matplotlib-users mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>As the new learner that Fernando alludes to, I'd like to second his 
>opinion.  As we speak, I'm looking through examples I've collected trying 
>to piece together something useful for my work.  The namespace conflicts 
>are a huge frustration, especially with regard to numarray/Numeric 
>overlap.  As a newbie, this is almost a show stopper.
>I'll figure it out eventually I hope...
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

John Hunter wrote:

>>>>>>"Derrick" == Derrick Snowden <Der...@no...> writes:
>>>>>>            
>>>>>>
>
>    Derrick> When I plot the data with missing values (say the mask is
>    Derrick> 1.0e20) it obviously screws up the range of the y limits.
>    Derrick> I've seen other packages which understand a missing_value
>    Derrick> attribute or a fill_value attribute and leave that
>    Derrick> section of the curve blank.  I was hoping for a behavior
>    Derrick> similar to Matlab, when the data vector contains NaNs.  I
>    Derrick> see some mention of this in the matplotlib-devel list
>    Derrick> (J. Whitaker's patch for pcolor) and I see a keyword
>    Derrick> argument for contourf that seems to address this
>    Derrick> situation.  Is there anything for line plots?
>
>Eric Firing contributes a patch for masked array support for line
>plots which is in CVS.  I haven't tried this with date plots but there
>is every reason to believe it will "just work"
>
>See examples/masked_demo.py in CVS.
>
>Let me know!
>
>JDH
>  
>
Some progress on this front...thanks for all your suggestions.  I tried 
to go with John's suggestion as it seems the most complete in the long 
run.  I had some success, and some errors.  First the success...

After downloading lines.py from cvs and reinstalling, I ran into an 
error trying to run the examples/masked_array.py.  The error message 
differed depending on whether I used numarray or numeric.  I won't 
include it here because I got past that point by downloading axes.py and 
reinstalling. 

1. When I tried
python masked_array.py --numarray

I got the following error and no plot...

[snowden@doris examples]$ python masked_demo.py --numarray
/usr/lib/python2.3/site-packages/matplotlib/__init__.py:636: 
UserWarning: Bad key "verbose.erro" on line 199 in 
/home/snowden/.matplotlibrc
  warnings.warn('Bad key "%s" on line %d in %s' % (key, cnt, fname))
loaded rc file /home/snowden/.matplotlibrc
matplotlib version 0.80
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.3.1
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/snowden/.ttffont.cache
matplotlib data path /usr/share/matplotlib
backend GTKAgg version 2.2.0
Traceback (most recent call last):
  File "masked_demo.py", line 19, in ?
    lines = plot(x, y, 'r', x, ym1, 'g', x, ym2, 'bo')
  File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line 
1899, in plot
    ret =  gca().plot(*args, **kwargs)
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 2491, 
in plot
    self.add_line(line)
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 732, 
in add_line
    self.update_datalim_numerix( xdata, ydata )
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 717, 
in update_datalim_numerix
    self.dataLim.update_numerix(x, y, not self.has_data())
ValueError: x and y must be equal length sequences


2. When I tried
python masked_array.py --Numeric

I get a plot, but while the plot is active an error message is 
periodically scrolling across the terminal screen.  (I'm using GTKAgg)

Traceback (most recent call last):
  File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py", 
line 163, in motion_notify_event
    FigureCanvasBase.motion_notify_event(self, x, y)
  File "/usr/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
line 743, in motion_notify_event
    func(event)
  File "/usr/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
line 997, in mouse_move
    s = event.inaxes.format_coord(event.xdata, event.ydata)
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 609, 
in format_coord
    xs = self.format_xdata(x)
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 591, 
in format_xdata
    func = self.xaxis.get_major_formatter().format_data
AttributeError: ScalarFormatter instance has no attribute 'format_data'

I suppose this is successful in that I get a plot to come on the screen 
but I doubt it's the solution you intended... Any ideas?


This brings me to my last question.  Has anyone out there had any 
problems with the sourceforge cvs?  I am unable to log in using the 
commands that are suggested on the sourceforege site.  I am at a 
government site and am behind a firewall.  Before I delve into cvs too 
deeply, I wondered if firewalls are known to not work well with cvs 
servers?  I have had some difficulties with rsync servers in the past.

Thanks again,
Derrick

Fernando Perez wrote:

> John Hunter wrote:
>
>>>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:
>>>>>>
>>
>>     >> I'm wondering if set is now a bad name for pylab to be using?
>>
>>     Tim> +1 for changing it.
>>
>>     Tim> I've also had this issue bite me when I was hacking together
>>     Tim> some code and wanted to use a python set. I'd be in favour of
>>     Tim> changing the pylab set to be called something else, although
>>     Tim> I don't have any good suggestions about what to change it
>>     Tim> to...
>>
>> Ouch, I hadn't thought of this.  In the past, consensus has been that
>> pylab should not override built-ins, eg the previous discussion on
>> min/max which led us to rename these functions to amin/amax.  Changing
>> set, unfortunately, will break a lot of scripts.  I think the best
>> plan of action is to define a new function pset or setp (setp for "set
>> property") which has the functionality of the old, and keep set around
>> for a release or two issuing a warning with a line number so people
>> can get their existing scripts cleaned up.
>
>
> I'd also suggest removing from all example code 'from pylab import *' 
> statements.  Frankly, after a while I've completely stopped using 
> 'from foo import *' in _any_ code I write, even small scripts.  All I 
> use these days is code like:
>
> import Numeric as N
> import scipy as S
> import pylab as P
>
> The only place where I think that from-import-* is OK is at an 
> interactive prompt, where you are just doing experiments and not 
> writing reusable code.
>
> Since the examples tend to be the place that people learn from, I 
> think it would be a good idea to encourage safer practices by banning 
> the dangerous import-* idiom from there.
>
> Just my opinion.
>
> Best,
>
> f
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

John Hunter wrote:
>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes:
> 
>     >> I'm wondering if set is now a bad name for pylab to be using?
> 
>     Tim> +1 for changing it.
> 
>     Tim> I've also had this issue bite me when I was hacking together
>     Tim> some code and wanted to use a python set. I'd be in favour of
>     Tim> changing the pylab set to be called something else, although
>     Tim> I don't have any good suggestions about what to change it
>     Tim> to...
> 
> Ouch, I hadn't thought of this.  In the past, consensus has been that
> pylab should not override built-ins, eg the previous discussion on
> min/max which led us to rename these functions to amin/amax.  Changing
> set, unfortunately, will break a lot of scripts.  I think the best
> plan of action is to define a new function pset or setp (setp for "set
> property") which has the functionality of the old, and keep set around
> for a release or two issuing a warning with a line number so people
> can get their existing scripts cleaned up.

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

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

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

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

Just my opinion.

Best,

f

On Wed, 18 May 2005, John Hunter <jdh...@ac...> wrote...

> >>>>> "Tim" =3D=3D Tim Leslie <ti...@cs...> writes:
>     >> I'm wondering if set is now a bad name for pylab to be using?
>=20
>     Tim> +1 for changing it.
>=20
>     Tim> I've also had this issue bite me when I was hacking together
>     Tim> some code and wanted to use a python set. I'd be in favour of
>     Tim> changing the pylab set to be called something else, although
>     Tim> I don't have any good suggestions about what to change it
>     Tim> to...
>=20
> Ouch, I hadn't thought of this.  In the past, consensus has been that
> pylab should not override built-ins, eg the previous discussion on
> min/max which led us to rename these functions to amin/amax.  Changing
> set, unfortunately, will break a lot of scripts.  I think the best
> plan of action is to define a new function pset or setp (setp for "set
> property") which has the functionality of the old, and keep set around
> for a release or two issuing a warning with a line number so people
> can get their existing scripts cleaned up.

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

=66rom pylab import *
setp =3D set
set =3D __builtins__.set

Tim

>=20
> JDH
>=20
`-

>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:
    >> I'm wondering if set is now a bad name for pylab to be using?

    Tim> +1 for changing it.

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

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

JDH

On Wed, 18 May 2005, John Gill <jn...@eu...> wrote...

> In python 2.4 set is available as a built-in type.
> 
> Now if I do:
> 
> from pylab import *
> 
> I get a function called set, which I can use to set properties on pylab 
> objects.
> 
> I'm wondering if set is now a bad name for pylab to be using?

+1 for changing it.

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

Tim

> 
> John
`-

In python 2.4 set is available as a built-in type.

Now if I do:

from pylab import *

I get a function called set, which I can use to set properties on pylab 
objects.

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

John

I'll have a play to see if I can make this a bit smarter.

John

Florian Lindner wrote:

> Am Dienstag, 17. Mai 2005 19:43 schrieb John Hunter:
> > >>>>> "Florian" == Florian Lindner <mai...@xg...> writes:
> >
> >     Florian> Hello, how does loc=0 (best) affects the placement of the
> >     Florian> legend? I can't really figure out any influence. There is
> >     Florian> space (on the upper left) where the legend could be
> >     Florian> placed without hiding any lines but it's still placed on
> >     Florian> the upper right.
> >
> > If what you say is correct, then it is a bug.  Please post a complete
> > example.
>
> It is correct.
>
> But the John Gill gave me a explanation of this behavior which is 
> correct for
> my case. It is not a bug, just a lazy implementation of the feature 
> and he is
> aware of that.
>
> Florian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click 
> <http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello,

I was wondering if there were any tips for people like myself that generate
plot images to be rendered for CGI scripts. I'd like to offer some of the
things I have learned on the subject thus far:

Changed .matplotlibrc's backend parameter to Agg. This seems to yield the best
quality output results. This way, I can compile without Tk and GTK support. I
did not find any way to easily call distutils with arguments to disable these
things, so I had to comment out the setup.py script after I patched it with
the FreeBSD port patches. This is on a box without a monitor, so I won't be
doing any interactive graphing anytime soon. :)

After realizing on my slower box (Pentium2 400MHz) that:

import pylab

takes a while. I just assumed most people don't restart matplotlib's runtime
initialization for every graph they produce, but rather, for interactive
graphing. This is pure guess, however.

Also, I'd like to know if using pylab directly is a bad idea for
non-interactive graphing. It seems to work okay but I've read through some
past mail on this list that importing matplotlib is better than pylab if
doing interface design(?) I also read that pylab tries to do more for setting
up the environment for interactive graphing, so maybe I don't need this.

I've done some profiling on the import using Python's profile
module and later found the hotshot module to help quite a bit with accuracy.
I'll try to post some of my speedups once I make sure they aren't pure hacks.
Some of it was the mathtext regexp work, but a surprising amount of time
was spent in a docstring magic/generation function!

I switched to using FastCGI to avoid some of the startup cost of matplotlib
on my slower server box. FastCGI is a way to speed up CGI programs, as the
name may imply. :) Unfortunately, stdout with FastCGI is wrapped in a special
little request object that isn't a true file object. I had to use the tempfile
Python module for matplotlib to write its output to. I had tracked down where
matplotlib did this (it was in some C module) but it's been a while since I
messed with it.

A final issue I ran into was permissions in a Web server environment. I run
the CGI application through FastCGI under a restricted user because it doesn't
need much permission to do anything else. Unfortunately, I noticed I have to
do some magic at runtime of my script to set my HOME path so that the
matplotlib font manager will write its ttfcache file to a place that the
CGI script can write to. It's not a big deal, but I did have to look through
the font manager source to figure out why it was raising an exception.

I hope this information helps others who want to produce great graphical
output using matplotlib that is targetted for the Web. I had to figure it out
for myself by searching and testing quite a bit.

My apologies for the long email. It's my first post that I tried to offer
suggestions to others instead of being a read-only list subscriber. :)


Thanks,

Brian

Hi Jeff,

yes, I did (fink-0.23.9.tar.gz install, ./bootstrap.sh etc. all went  
well and I was able to re-install emacs which had also broken with  
the 10.4 upgrade.)
I shall await 10.4 upgrades.

In the interim,

http://pythonmac.org/packages/matplotlib-0.72.1-py2.3-macosx10.3.zip
http://pythonmac.org/packages/numarray-1.1.1-py2.3-macosx10.3.zip
http://pythonmac.org/packages/TigerPython23Compat.pkg.zip (fixes up  
site-packages location)

have allowed me to get pylab imported, now I just need to get a  
backend compiled (gtk is my preferred backend).

thanks,

Graeme

On 18/05/2005, at 12:06 AM, Jeff Whitaker wrote:

> Graeme O'Keefe wrote:
>
>
>> I have just upgraded to OS X 10.4 on two machines. On one  
>> machine,  pylab worked fine, on my notebook it hangs. I have begun  
>> trying to  rebuild my fink tree but bomb at glib 2.6.2 / gtk+,  
>> pango-1.8.0 using  fink as well as standalone installs for old  
>> items (pango is at 1.6 on  fink, need 1.8 for gtk+2.6.0).
>>
>> As an aside, numarray install bombed with gcc4.0 so I had to  
>> revert  to gcc3.3.
>>
>> Anyone else had problems with OS X 10.4 and pylab?
>>
>> regards,
>>
>> Graeme
>>
>>
>>
>>
>>
> Graeme:  Did you follow the instructions for upgrading fink for  
> 10.4 on the fink home page?  It's a tricky upgrade - many (if not  
> all) packages need to rebuilt.  Many packages are not yet working,  
> since many developers (like me) don't yet have 10.4.
>
> -Jeff
>
>
> -- 
> Jeffrey S. Whitaker         Phone : (303)497-6313
> NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
> 325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
> Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124
>
>

>>>>> "Derrick" == Derrick Snowden <Der...@no...> writes:

    Derrick> When I plot the data with missing values (say the mask is
    Derrick> 1.0e20) it obviously screws up the range of the y limits.
    Derrick> I've seen other packages which understand a missing_value
    Derrick> attribute or a fill_value attribute and leave that
    Derrick> section of the curve blank.  I was hoping for a behavior
    Derrick> similar to Matlab, when the data vector contains NaNs.  I
    Derrick> see some mention of this in the matplotlib-devel list
    Derrick> (J. Whitaker's patch for pcolor) and I see a keyword
    Derrick> argument for contourf that seems to address this
    Derrick> situation.  Is there anything for line plots?

Eric Firing contributes a patch for masked array support for line
plots which is in CVS.  I haven't tried this with date plots but there
is every reason to believe it will "just work"

See examples/masked_demo.py in CVS.

Let me know!

JDH

OK, I've passed the glitches with the dates and am on to plotting a time 
series of data using plot_date.  My data are currently represented as a 
masked array and there are missing values.  I vaguely remember seeing 
something about this while I was reading but I can't for the life of me 
find it and the search facility on the sourceforge mailing list site is 
down.

When I plot the data with missing values (say the mask is 1.0e20) it 
obviously screws up the range of the y limits.  I've seen other packages 
which understand a missing_value attribute or a fill_value attribute and 
leave that section of the curve blank.  I was hoping for a behavior 
similar to Matlab, when the data vector contains NaNs.  I see some 
mention of this in the matplotlib-devel list (J. Whitaker's patch for 
pcolor) and I see a keyword argument for contourf that seems to address 
this situation.  Is there anything for line plots?

Thanks again,
Derrick

Am Dienstag, 17. Mai 2005 19:43 schrieb John Hunter:
> >>>>> "Florian" == Florian Lindner <mai...@xg...> writes:
>
>     Florian> Hello, how does loc=0 (best) affects the placement of the
>     Florian> legend? I can't really figure out any influence. There is
>     Florian> space (on the upper left) where the legend could be
>     Florian> placed without hiding any lines but it's still placed on
>     Florian> the upper right.
>
> If what you say is correct, then it is a bug.  Please post a complete
> example.

It is correct.

But the John Gill gave me a explanation of this behavior which is correct for 
my case. It is not a bug, just a lazy implementation of the feature and he is 
aware of that.

Florian

This might be a feature rather than a bug.

The legend auto-placement code is a bit lazy -- due to the fact that I 
wrote it rather than JDH :)

Anyway, it only tries to avoid the points that define a line, rather 
than the lines themselves.

Much of the time that works well, but since it only takes two points to 
define a line you can end up with the lines crossing the legend.   The 
good news is that if a line does cross the legend, and you can see a 
better position for the legend then it almost surely means that the line 
is straight throughout the region where it crosses the legend.

Try using the pan/zoom buttons on your plot to move a point into the 
legend area and it should jump out of the way.

Eg: try this little snippet -- use your pan/zoom skills to position one 
of the dots over the legend ;)

from pylab import *
plot(range(5), 'o-', label='oops')
legend(loc=0)
show()

John

John Hunter wrote:

> >>>>> "Florian" == Florian Lindner <mai...@xg...> writes:
>
>     Florian> Hello, how does loc=0 (best) affects the placement of the
>     Florian> legend? I can't really figure out any influence. There is
>     Florian> space (on the upper left) where the legend could be
>     Florian> placed without hiding any lines but it's still placed on
>     Florian> the upper right.
>
> If what you say is correct, then it is a bug.  Please post a complete
> example.
>
> JDH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click 
> <http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Derrick Snowden wrote:

> You're probably right about this, months are ambiguously defined.  But, 
> I'm even more confused now about the documentation that you found.  I'm 
> hoping this is  a version issue but I couldn't find a function 
> definition like that.  I tried using pydoc and pdoc, pdef, pinfo etc in 
> ipython on a linux machine as well as a Windows machine.  The only thing 
> I can come up with is the following
> 
> 
> class timedelta(__builtin__.object)
>      	Difference between two datetime values.
> 
> Where am I going wrong?

I ran into the same problem, the docstring-based docs for that module are 
really crappy (and that's all ipython can find).  So I reverted to the module 
listing in the HTML python docs to read the full docs for the datetime module. 
  Here's the online version (what I pasted was from the local copy for my 
version, 2.3.4):

http://docs.python.org/lib/module-datetime.html

HTH,

f

Fernando Perez wrote:
> Derrick Snowden wrote:
> 
>> Finally, I find the documentation for datetime.timedelta to be pretty 
>> sparse.  I was trying to construct a datetime sequence using 
>> matplotlib.dates.drange which had a monthly timestep.
>>
>> delta = datetime.timedelta(months=1) didn't seem to work.  I tried a 
>> few variations on this to no avail.
> 
> 
> Well, the docs for timedelta give this constructor:
> 
> ============================================
> class timedelta(days=0, seconds=0, microseconds=0, milliseconds=0, 
> minutes=0, hours=0, weeks=0)
> 
>     All arguments are optional. Arguments may be ints, longs, or floats, 
> and may be positive or negative.
> ============================================
> 
> I'd guess that the reason why you don't see years nor months in there is 
> because those can't be uniquely defined in terms of fundamental time 
> units (for the sake of simplicity, in multiples or submultiples of 
> seconds).
You're probably right about this, months are ambiguously defined.  But, 
I'm even more confused now about the documentation that you found.  I'm 
hoping this is  a version issue but I couldn't find a function 
definition like that.  I tried using pydoc and pdoc, pdef, pinfo etc in 
ipython on a linux machine as well as a Windows machine.  The only thing 
I can come up with is the following


class timedelta(__builtin__.object)
     	Difference between two datetime values.

Where am I going wrong?

> 
> I'm not an expert on handling time-based data, so this is just a common 
> sense guess.
> 
> Best,
> 
> f

Derrick Snowden wrote:

> Finally, I find the documentation for datetime.timedelta to be pretty 
> sparse.  I was trying to construct a datetime sequence using 
> matplotlib.dates.drange which had a monthly timestep.
> 
> delta = datetime.timedelta(months=1) didn't seem to work.  I tried a few 
> variations on this to no avail.

Well, the docs for timedelta give this constructor:

============================================
class timedelta(days=0, seconds=0, microseconds=0, milliseconds=0, minutes=0, 
hours=0, weeks=0)

     All arguments are optional. Arguments may be ints, longs, or floats, and 
may be positive or negative.
============================================

I'd guess that the reason why you don't see years nor months in there is 
because those can't be uniquely defined in terms of fundamental time units 
(for the sake of simplicity, in multiples or submultiples of seconds).

I'm not an expert on handling time-based data, so this is just a common sense 
guess.

Best,

f

Hi all,

I'm new to matplotlib and trying to adapt some of the examples to my own 
data.  Most of the time I read data from a netcdf file using the 
Scientific.IO.NetCDF module.  When I read a time variable it usually has 
a units attribute that looks something like

"days since 1900-01-01 00:00:00 -5".

The units of measurement (here it was days) can be hours, seconds, 
weeks, whatever.  Most of the examples in the mpl examples directory 
that deal with dates, start with the time information already parsed 
into year, month, day etc and then they create a datetime instance.  Any 
pointers on parsing a serial date like the one I have into year, month, 
day in a somewhat general way?  I currently use a package (cdat) which 
doesn't compile on Windows yet and I need a windows and unix solution.

Finally, I find the documentation for datetime.timedelta to be pretty 
sparse.  I was trying to construct a datetime sequence using 
matplotlib.dates.drange which had a monthly timestep.

delta = datetime.timedelta(months=1) didn't seem to work.  I tried a few 
variations on this to no avail.

Thanks for any suggestions.
Derrick

Keith Goodman wrote:
> Your screenshots---WOW!
> 
> I installed matplotlib 0.80 (from source). Now the screenshots are on
> my computer. But I can't interact with them. As soon as I enter show()
> the plot appears in both python and ipython and then the prompt
> disappears. If I type, for example, xlabel('Year') and ylabel('Number
> of geeky science fiction desktop backgrounds') nothing happens. (I can
> use the GUI controls on the plot.)
> 
> Eventually I enter control-c in ipython and get
> 
> $ python2.3-ipython

You should use 'ipython -pylab' instead, so that ipython can coordinate the 
gui and python threads for you.

Cheers,

f

>>>>> "Keith" == Keith Goodman <kwg...@gm...> writes:


    Keith> Your screenshots---WOW!  I installed matplotlib 0.80 (from

Thanks!

    Keith> source). Now the screenshots are on my computer. But I
    Keith> can't interact with them. As soon as I enter show() the
    Keith> plot appears in both python and ipython and then the prompt
    Keith> disappears. If I type, for example, xlabel('Year') and
    Keith> ylabel('Number of geeky science fiction desktop
    Keith> backgrounds') nothing happens. (I can use the GUI controls
    Keith> on the plot.)

    Keith> Eventually I enter control-c in ipython and get

Run ipython in pylab mode 

 > ipython -pylab

You then do not need to import pylab (ipython does this for you) and
you do not, indeed must not, use show.

See 

  http://matplotlib.sourceforge.net/interactive.html

and

  http://matplotlib.sourceforge.net/faq.html#SHOW

Have fun...

JDH

Your screenshots---WOW!

I installed matplotlib 0.80 (from source). Now the screenshots are on
my computer. But I can't interact with them. As soon as I enter show()
the plot appears in both python and ipython and then the prompt
disappears. If I type, for example, xlabel('Year') and ylabel('Number
of geeky science fiction desktop backgrounds') nothing happens. (I can
use the GUI controls on the plot.)

Eventually I enter control-c in ipython and get

$ python2.3-ipython
Python 2.3.5 (#2, May  4 2005, 08:51:39)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.13 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from pylab import *

In [2]: plot([1,2,3,4])
Out[2]: [<matplotlib.lines.Line2D instance at 0x405cfe6c>]

In [3]: show()
xlabel('Year')
ylabel('Number of geeky science fiction desktop backgrounds')
---------------------------------------------------------------------------
exceptions.KeyboardInterrupt                         Traceback (most
recent call last)

/home/me/<console>

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py in
show(mainloop)
     85
     86     if mainloop and gtk.main_level() =3D=3D 0:
---> 87         gtk.main()
     88
     89

KeyboardInterrupt:

In [4]:

>>>>> "Florian" == Florian Lindner <mai...@xg...> writes:

    Florian> Hello, how does loc=0 (best) affects the placement of the
    Florian> legend? I can't really figure out any influence. There is
    Florian> space (on the upper left) where the legend could be
    Florian> placed without hiding any lines but it's still placed on
    Florian> the upper right.

If what you say is correct, then it is a bug.  Please post a complete
example.

JDH

Hello,
how does loc=0 (best) affects the placement of the legend? I can't really 
figure out any influence. There is space (on the upper left) where the legend 
could be placed without hiding any lines but it's still placed on the upper 
right.

Thanks,

Florian

On May 17, 2005, at 11:50 AM, John Hunter wrote:

>>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>
>     Perry> Yes, indeed.
>
> I know you don't want to get into the business of porting numarray
> functionality back to Numeric :-) but do you know of an easy way to
> generalize this to N dimensions for Numeric.  I took a brief look at
> how numarray did it, and it relies on choose under the hood, but it
> didn't look like it would be straightforward to port to Numeric.
>
> An Nd "find" would be useful in mpl, at least until the whole array
> object scenario stabilizes.
>
> JDH

numarray does it at a low level which wouldn't be easy to duplicate in 
Numeric. But I don't think it is that hard to do in Python so long as 
you don't mind using ravel() and generating an intermediate index 
array. Something like (not checked or tested, surely there's a mistake 
in it somewhere)?

def find(condition):
     ind = nonzero(ravel(condition))
     cshape = multiply.accumulate(condition.shape)[-1:0:-1]
     indices = [] # probably better done as a list comprehension but I'm 
too lazy to look it up
     for size in cshape: indices.append(ind//size)
     indices.append(ind % condition.shape[-1]
     return tuple(indices)


But I may be missing a complication.

Perry