matplotlib-devel Mailing List for matplotlib (Page 4)

There was a question on the matplotlib-users list about symbols in 
scatter, that made me realize that the new "marker = (5,0)" ... syntax, 
that I contributed some time ago, were not documented. So I tried to 
write a doc string.
Can anyone please check this and add the patch? Btw: shouldn't the 
"verts" keyword be removed, since marker=(verts,0) is equivalent ?
Manuel

Great -- hopefully that saved you some API re-arrangement pain. No 
problem on shuffling mpl_sizer around -- please go ahead do it if you 
have time.
-Andrew
Jeff Whitaker wrote:
> Andrew: Thanks, you've convinced me. Is it OK with you if I go ahead 
> and make those changes to mplsizer at the same time I do basemap?
>
> -Jeff
>

Andrew Straw wrote:
> Jeff Whitaker wrote:
> 
>> Darren Dale wrote:
>> 
>>> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>>> 
>>> 
>>>> Andrew Straw wrote:
>>>> 
>>>> 
>>>>> As the author of the only other known MPL toolkit (at least in the MPL
>>>>> tree), I'm happy with the idea of using a namespace package for
>>>>> mpl_toolkits. I understand your proposal to mean that each toolkit
>>>>> would
>>>>> have a directory structure:
>>>>>
>>>>> setup.py
>>>>> lib/
>>>>> mpl_toolkits/
>>>>> __init__.py (empty)
>>>>> basemap/
>>>>> __init__.py
>>>>> other_files.py
>>>>>
>>>>> This is OK with me, but I question is whether it's necessary to
>>>>> have the
>>>>> "lib" directory -- it seems entirely redundant. I'm fine with either
>>>>> way, though.
>>>>>
>>>>> -Andrew
>>>>> 
>>>>> 
>>>> Andrew: Yes, that's it, except that all the __init__.py files must be
>>>> empty, not just the first one.
>>>> 
>>>> 
>>> Just to clarify, all __init__.pys must be empty? I have no experience
>>> with setuptools, but the way I read the documentation, it sounded
>>> like only the __init__.py in the namespace package needed to be
>>> empty, like Andrew showed.
>>>
>>> Hopefully not muddying the waters,
>>> Darren
>>> 
>>> 
>> Darren: I was assuming they both needed to be namespace packages
>> (mpl_tookits and mpl_toolkits.basemap).
>> I just went back and re-read it, and now I'm just not sure ...
>> The waters are muddy. 
>> 
> I dealt with this recently in my as-yet-to-be-really-announced set of
> packages for realtime image analysis: motmot, at
> http://code.astraw.com/projects/motmot
>
> I'm reasonably certain that Darren is correct -- __init__.py only needs
> to be empty if the package is a namespace package. In other words, if
> you wanted to have additional packages in the mpl_toolkits.basemap
> namespace, mpl_toolkits/basemap/__init__.py would have to be empty. If
> you don't see anything else in that namespace, you can keep __init__.py
> containing whatever it does.
>
> Note that for 2nd level namespace packages to work at all, you need the
> most recent setuptools (0.6c7), as a bug was recently discovered by the
> Enthought Tool Suite folks regarding this feature.
> 
Andrew: Thanks, you've convinced me. Is it OK with you if I go ahead 
and make those changes to mplsizer at the same time I do basemap?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Jeff Whitaker wrote:
> Darren Dale wrote:
>> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>> 
>>> Andrew Straw wrote:
>>> 
>>>> As the author of the only other known MPL toolkit (at least in the MPL
>>>> tree), I'm happy with the idea of using a namespace package for
>>>> mpl_toolkits. I understand your proposal to mean that each toolkit
>>>> would
>>>> have a directory structure:
>>>>
>>>> setup.py
>>>> lib/
>>>> mpl_toolkits/
>>>> __init__.py (empty)
>>>> basemap/
>>>> __init__.py
>>>> other_files.py
>>>>
>>>> This is OK with me, but I question is whether it's necessary to
>>>> have the
>>>> "lib" directory -- it seems entirely redundant. I'm fine with either
>>>> way, though.
>>>>
>>>> -Andrew
>>>> 
>>> Andrew: Yes, that's it, except that all the __init__.py files must be
>>> empty, not just the first one.
>>> 
>>
>> Just to clarify, all __init__.pys must be empty? I have no experience
>> with setuptools, but the way I read the documentation, it sounded
>> like only the __init__.py in the namespace package needed to be
>> empty, like Andrew showed.
>>
>> Hopefully not muddying the waters,
>> Darren
>> 
> Darren: I was assuming they both needed to be namespace packages
> (mpl_tookits and mpl_toolkits.basemap).
> I just went back and re-read it, and now I'm just not sure ...
> The waters are muddy. 
I dealt with this recently in my as-yet-to-be-really-announced set of
packages for realtime image analysis: motmot, at
http://code.astraw.com/projects/motmot
I'm reasonably certain that Darren is correct -- __init__.py only needs
to be empty if the package is a namespace package. In other words, if
you wanted to have additional packages in the mpl_toolkits.basemap
namespace, mpl_toolkits/basemap/__init__.py would have to be empty. If
you don't see anything else in that namespace, you can keep __init__.py
containing whatever it does.
Note that for 2nd level namespace packages to work at all, you need the
most recent setuptools (0.6c7), as a bug was recently discovered by the
Enthought Tool Suite folks regarding this feature.

Darren Dale wrote:
> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
> 
>> Andrew Straw wrote:
>> 
>>> As the author of the only other known MPL toolkit (at least in the MPL
>>> tree), I'm happy with the idea of using a namespace package for
>>> mpl_toolkits. I understand your proposal to mean that each toolkit would
>>> have a directory structure:
>>>
>>> setup.py
>>> lib/
>>> mpl_toolkits/
>>> __init__.py (empty)
>>> basemap/
>>> __init__.py
>>> other_files.py
>>>
>>> This is OK with me, but I question is whether it's necessary to have the
>>> "lib" directory -- it seems entirely redundant. I'm fine with either
>>> way, though.
>>>
>>> -Andrew
>>> 
>> Andrew: Yes, that's it, except that all the __init__.py files must be
>> empty, not just the first one.
>> 
>
> Just to clarify, all __init__.pys must be empty? I have no experience with 
> setuptools, but the way I read the documentation, it sounded like only the 
> __init__.py in the namespace package needed to be empty, like Andrew showed.
>
> Hopefully not muddying the waters,
> Darren
> 
Darren: I was assuming they both needed to be namespace packages 
(mpl_tookits and mpl_toolkits.basemap).
I just went back and re-read it, and now I'm just not sure ... 
The waters are muddy.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
> Andrew Straw wrote:
> > As the author of the only other known MPL toolkit (at least in the MPL
> > tree), I'm happy with the idea of using a namespace package for
> > mpl_toolkits. I understand your proposal to mean that each toolkit would
> > have a directory structure:
> >
> > setup.py
> > lib/
> > mpl_toolkits/
> > __init__.py (empty)
> > basemap/
> > __init__.py
> > other_files.py
> >
> > This is OK with me, but I question is whether it's necessary to have the
> > "lib" directory -- it seems entirely redundant. I'm fine with either
> > way, though.
> >
> > -Andrew
>
> Andrew: Yes, that's it, except that all the __init__.py files must be
> empty, not just the first one.
Just to clarify, all __init__.pys must be empty? I have no experience with 
setuptools, but the way I read the documentation, it sounded like only the 
__init__.py in the namespace package needed to be empty, like Andrew showed.
Hopefully not muddying the waters,
Darren

Andrew Straw wrote:
> As the author of the only other known MPL toolkit (at least in the MPL
> tree), I'm happy with the idea of using a namespace package for
> mpl_toolkits. I understand your proposal to mean that each toolkit would
> have a directory structure:
>
> setup.py
> lib/
> mpl_toolkits/
> __init__.py (empty)
> basemap/
> __init__.py
> other_files.py
>
> This is OK with me, but I question is whether it's necessary to have the
> "lib" directory -- it seems entirely redundant. I'm fine with either
> way, though.
>
> -Andrew
Andrew: Yes, that's it, except that all the __init__.py files must be 
empty, not just the first one. Additionally, there would be a file 
'api.py' in the same directory as 'other_files.py' that would have all 
the stuff that previously was imported directly into __init__.py. The 
rationale for this convention is discussed at 
http://neuroimaging.scipy.org/neuroimaging/ni/ticket/86, and is being 
used now in several projects.
 The lib directory is not necessary, you would just change the
package_dirs = {'':'lib'}
line in setup.py accordingly.
-Jeff
> 
>
> Jeff Whitaker wrote:
> 
>> Now that the transforms branch has merged with the trunk, I'd like to 
>> resurrect namespace packages so that toolkits will work again when 
>> matplotlib is installed as an egg. As was discussed in a previous 
>> thread, all __init__.py files in the toolkit hierarchy must be empty 
>> (aside declare_namespace statement). Since lib/matplotlib/__init__.py 
>> contains a lot of important stuff, I think the path of least resistance 
>> is to move the toolkits out of lib/matplotlib and into a separate 
>> directory lib/mpl_toolkits. The semantics of importing a toolkit would 
>> have to change from
>>
>> import matplotlib.toolkits.toolkit
>>
>> to
>>
>> import mpl_toolkit.toolkit.
>>
>> Of course, all the toolkit __init__.py files would need to be emptied. 
>> In the case of basemap, this would be changing imports from
>>
>> from matplotlib.toolkits.basemap import Basemap
>>
>> to something like
>>
>> from mpl_toolkits.basemap.api import Basemap
>>
>> All the stuff now imported directly into __init__.py would go in api.py.
>>
>> I've tried this in my local tree and it seems to work fine. Does this 
>> sound reasonable? If there's general agreement, I can make the 
>> necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
>>
>> -Jeff
>>
>> 
>> 
>
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Ted Drain wrote:
> Does this proposal change the way people access this 
> functionality? We have a lot of scripts (and a lot of users with 
> scripts) that use basemap and it tends to be extremely annoying to 
> people when their scripts suddenly break.
>
> Ted
> 
Ted: Unfortunately it would break scripts, but only the initial import.
Instead of
from matplotlib.toolkits.basemap import Basemap
you would do
from mpl_toolkits.basemap.api import Basemap
Everything else would be the same. 
-Jeff
> At 03:34 PM 1/9/2008, Andrew Straw wrote:
> 
>> As the author of the only other known MPL toolkit (at least in the MPL
>> tree), I'm happy with the idea of using a namespace package for
>> mpl_toolkits. I understand your proposal to mean that each toolkit would
>> have a directory structure:
>>
>> setup.py
>> lib/
>> mpl_toolkits/
>> __init__.py (empty)
>> basemap/
>> __init__.py
>> other_files.py
>>
>> This is OK with me, but I question is whether it's necessary to have the
>> "lib" directory -- it seems entirely redundant. I'm fine with either
>> way, though.
>>
>> -Andrew
>>
>> Jeff Whitaker wrote:
>> 
>>> Now that the transforms branch has merged with the trunk, I'd like to
>>> resurrect namespace packages so that toolkits will work again when
>>> matplotlib is installed as an egg. As was discussed in a previous
>>> thread, all __init__.py files in the toolkit hierarchy must be empty
>>> (aside declare_namespace statement). Since lib/matplotlib/__init__.py
>>> contains a lot of important stuff, I think the path of least resistance
>>> is to move the toolkits out of lib/matplotlib and into a separate
>>> directory lib/mpl_toolkits. The semantics of importing a toolkit would
>>> have to change from
>>>
>>> import matplotlib.toolkits.toolkit
>>>
>>> to
>>>
>>> import mpl_toolkit.toolkit.
>>>
>>> Of course, all the toolkit __init__.py files would need to be emptied.
>>> In the case of basemap, this would be changing imports from
>>>
>>> from matplotlib.toolkits.basemap import Basemap
>>>
>>> to something like
>>>
>>> from mpl_toolkits.basemap.api import Basemap
>>>
>>> All the stuff now imported directly into __init__.py would go in api.py.
>>>
>>> I've tried this in my local tree and it seems to work fine. Does this
>>> sound reasonable? If there's general agreement, I can make the
>>> necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
>>>
>>> -Jeff
>>>
>>>
>>> 
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> Ted Drain Jet Propulsion Laboratory ted...@jp... 
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Does this proposal change the way people access this 
functionality? We have a lot of scripts (and a lot of users with 
scripts) that use basemap and it tends to be extremely annoying to 
people when their scripts suddenly break.
Ted
At 03:34 PM 1/9/2008, Andrew Straw wrote:
>As the author of the only other known MPL toolkit (at least in the MPL
>tree), I'm happy with the idea of using a namespace package for
>mpl_toolkits. I understand your proposal to mean that each toolkit would
>have a directory structure:
>
>setup.py
>lib/
> mpl_toolkits/
> __init__.py (empty)
> basemap/
> __init__.py
> other_files.py
>
>This is OK with me, but I question is whether it's necessary to have the
>"lib" directory -- it seems entirely redundant. I'm fine with either
>way, though.
>
>-Andrew
>
>Jeff Whitaker wrote:
> > Now that the transforms branch has merged with the trunk, I'd like to
> > resurrect namespace packages so that toolkits will work again when
> > matplotlib is installed as an egg. As was discussed in a previous
> > thread, all __init__.py files in the toolkit hierarchy must be empty
> > (aside declare_namespace statement). Since lib/matplotlib/__init__.py
> > contains a lot of important stuff, I think the path of least resistance
> > is to move the toolkits out of lib/matplotlib and into a separate
> > directory lib/mpl_toolkits. The semantics of importing a toolkit would
> > have to change from
> >
> > import matplotlib.toolkits.toolkit
> >
> > to
> >
> > import mpl_toolkit.toolkit.
> >
> > Of course, all the toolkit __init__.py files would need to be emptied.
> > In the case of basemap, this would be changing imports from
> >
> > from matplotlib.toolkits.basemap import Basemap
> >
> > to something like
> >
> > from mpl_toolkits.basemap.api import Basemap
> >
> > All the stuff now imported directly into __init__.py would go in api.py.
> >
> > I've tried this in my local tree and it seems to work fine. Does this
> > sound reasonable? If there's general agreement, I can make the
> > necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
> >
> > -Jeff
> >
> >
>
>
>-------------------------------------------------------------------------
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

As the author of the only other known MPL toolkit (at least in the MPL
tree), I'm happy with the idea of using a namespace package for
mpl_toolkits. I understand your proposal to mean that each toolkit would
have a directory structure:
setup.py
lib/
 mpl_toolkits/
 __init__.py (empty)
 basemap/
 __init__.py
 other_files.py
This is OK with me, but I question is whether it's necessary to have the
"lib" directory -- it seems entirely redundant. I'm fine with either
way, though.
-Andrew 
Jeff Whitaker wrote:
> Now that the transforms branch has merged with the trunk, I'd like to 
> resurrect namespace packages so that toolkits will work again when 
> matplotlib is installed as an egg. As was discussed in a previous 
> thread, all __init__.py files in the toolkit hierarchy must be empty 
> (aside declare_namespace statement). Since lib/matplotlib/__init__.py 
> contains a lot of important stuff, I think the path of least resistance 
> is to move the toolkits out of lib/matplotlib and into a separate 
> directory lib/mpl_toolkits. The semantics of importing a toolkit would 
> have to change from
>
> import matplotlib.toolkits.toolkit
>
> to
>
> import mpl_toolkit.toolkit.
>
> Of course, all the toolkit __init__.py files would need to be emptied. 
> In the case of basemap, this would be changing imports from
>
> from matplotlib.toolkits.basemap import Basemap
>
> to something like
>
> from mpl_toolkits.basemap.api import Basemap
>
> All the stuff now imported directly into __init__.py would go in api.py.
>
> I've tried this in my local tree and it seems to work fine. Does this 
> sound reasonable? If there's general agreement, I can make the 
> necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
>
> -Jeff
>
> 

Thank you, Mike.
On Wednesday 09 January 2008 04:36:21 pm Michael Droettboom wrote:
> I have something that works in r4833. It requires a clean rebuild,
> since the change was only to a header file. It produces no measurable
> slowdown on my fps test. (Of course, Eric's suggestion probably
> wouldn't have either...)
>
> Please let me know how this works for you.
>
> The nice thing about the new implementation is that it is in common
> code, so all backends should support NaNs (whereas before it was only
> Agg, Ps and Pdf). It does, curiously, also work on polygons etc. (the
> NaN-containing vertices are skipped), which doesn't make a whole lot of
> sense, but it's actually harder not to do that. IMHO, if you're putting
> NaNs in polygons you're asking for trouble anyway... If you are, speak
> up now... ;)
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I think this is an oversight on my part when doing the rewrite. The old
> > trunk had special code to deal with NaNs in draw_lines (in some
> > backends, but not all). Since draw_lines disappeared (it was replaced
> > with draw_path), this functionality fell through the cracks. I think
> > somehow bringing the old solution over (without the backend dependence)
> > may be faster than what Eric is proposing, since it is done "on-the-fly"
> > in C (at least for Agg) and doesn't require allocating any more memory
> > for the mask.
> >
> > However, it feels a bit dirty on a gut level to allow two subtly
> > different ways to specify data with gaps. I almost lean toward forcing
> > the user to provide masked arrays if that's what they want to do -- but
> > that's probably not realistic. I think Darren is right -- sometimes
> > NaN's come up when you least expect them, after many other data sets and
> > plots have already worked, and it would be bad for the app to suddenly
> > just fail in that case.
> >
> > I'll look into bringing the old way over to the new code. Failing that,
> > I think Eric's suggestion is quite reasonable.
> >
> > Cheers,
> > Mike
> >
> > Eric Firing wrote:
> >> Darren Dale wrote:
> >>> It looks like the new transforms codebase does not support data that
> >>> contains NaNs the way the old trunk did:
> >>>
> >>> plot([1,2,NaN,4,5]) produces a plot with no line break
> >>> plot([NaN,2,3,4,5]) produces a plot with no line
> >>>
> >>> I know use of NaN's is not encouraged, and we have discussed it on this
> >>> list. But since they are sometimes unintended and unavoidable, I'm
> >>> reporting the behavior so people are not surprised when they get an
> >>> empty plot.
> >>>
> >>> Darren
> >>
> >> This comes up often enough that it might be worth doing automatic
> >> masking of NaNs in the high-level argument processing wherever we are
> >> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced
> >> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding
> >> this overhead, but now I think the overhead might be negligible in
> >> almost all cases. It looks like it would be on the order of
> >> milliseconds per high-level call, where by high-level call I mean plot,
> >> pcolor, quiver, etc. (either via pylab or Axes method).
> >>
> >> Eric
> >>
> >> ------------------------------------------------------------------------
> >>- Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
> >>lace _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

I have something that works in r4833. It requires a clean rebuild, 
since the change was only to a header file. It produces no measurable 
slowdown on my fps test. (Of course, Eric's suggestion probably 
wouldn't have either...)
Please let me know how this works for you.
The nice thing about the new implementation is that it is in common 
code, so all backends should support NaNs (whereas before it was only 
Agg, Ps and Pdf). It does, curiously, also work on polygons etc. (the 
NaN-containing vertices are skipped), which doesn't make a whole lot of 
sense, but it's actually harder not to do that. IMHO, if you're putting 
NaNs in polygons you're asking for trouble anyway... If you are, speak 
up now... ;)
Cheers,
Mike
Michael Droettboom wrote:
> I think this is an oversight on my part when doing the rewrite. The old 
> trunk had special code to deal with NaNs in draw_lines (in some 
> backends, but not all). Since draw_lines disappeared (it was replaced 
> with draw_path), this functionality fell through the cracks. I think 
> somehow bringing the old solution over (without the backend dependence) 
> may be faster than what Eric is proposing, since it is done "on-the-fly" 
> in C (at least for Agg) and doesn't require allocating any more memory 
> for the mask.
> 
> However, it feels a bit dirty on a gut level to allow two subtly 
> different ways to specify data with gaps. I almost lean toward forcing 
> the user to provide masked arrays if that's what they want to do -- but 
> that's probably not realistic. I think Darren is right -- sometimes 
> NaN's come up when you least expect them, after many other data sets and 
> plots have already worked, and it would be bad for the app to suddenly 
> just fail in that case.
> 
> I'll look into bringing the old way over to the new code. Failing that, 
> I think Eric's suggestion is quite reasonable.
> 
> Cheers,
> Mike
> 
> Eric Firing wrote:
>> Darren Dale wrote:
>>> It looks like the new transforms codebase does not support data that contains 
>>> NaNs the way the old trunk did:
>>>
>>> plot([1,2,NaN,4,5]) produces a plot with no line break
>>> plot([NaN,2,3,4,5]) produces a plot with no line
>>>
>>> I know use of NaN's is not encouraged, and we have discussed it on this list. 
>>> But since they are sometimes unintended and unavoidable, I'm reporting the 
>>> behavior so people are not surprised when they get an empty plot.
>>>
>>> Darren
>> This comes up often enough that it might be worth doing automatic 
>> masking of NaNs in the high-level argument processing wherever we are 
>> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
>> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
>> this overhead, but now I think the overhead might be negligible in 
>> almost all cases. It looks like it would be on the order of 
>> milliseconds per high-level call, where by high-level call I mean plot, 
>> pcolor, quiver, etc. (either via pylab or Axes method).
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think this is an oversight on my part when doing the rewrite. The old 
trunk had special code to deal with NaNs in draw_lines (in some 
backends, but not all). Since draw_lines disappeared (it was replaced 
with draw_path), this functionality fell through the cracks. I think 
somehow bringing the old solution over (without the backend dependence) 
may be faster than what Eric is proposing, since it is done "on-the-fly" 
in C (at least for Agg) and doesn't require allocating any more memory 
for the mask.
However, it feels a bit dirty on a gut level to allow two subtly 
different ways to specify data with gaps. I almost lean toward forcing 
the user to provide masked arrays if that's what they want to do -- but 
that's probably not realistic. I think Darren is right -- sometimes 
NaN's come up when you least expect them, after many other data sets and 
plots have already worked, and it would be bad for the app to suddenly 
just fail in that case.
I'll look into bringing the old way over to the new code. Failing that, 
I think Eric's suggestion is quite reasonable.
Cheers,
Mike
Eric Firing wrote:
> Darren Dale wrote:
>> It looks like the new transforms codebase does not support data that contains 
>> NaNs the way the old trunk did:
>>
>> plot([1,2,NaN,4,5]) produces a plot with no line break
>> plot([NaN,2,3,4,5]) produces a plot with no line
>>
>> I know use of NaN's is not encouraged, and we have discussed it on this list. 
>> But since they are sometimes unintended and unavoidable, I'm reporting the 
>> behavior so people are not surprised when they get an empty plot.
>>
>> Darren
> 
> This comes up often enough that it might be worth doing automatic 
> masking of NaNs in the high-level argument processing wherever we are 
> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
> this overhead, but now I think the overhead might be negligible in 
> almost all cases. It looks like it would be on the order of 
> milliseconds per high-level call, where by high-level call I mean plot, 
> pcolor, quiver, etc. (either via pylab or Axes method).
> 
> Eric
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Darren Dale wrote:
> It looks like the new transforms codebase does not support data that contains 
> NaNs the way the old trunk did:
> 
> plot([1,2,NaN,4,5]) produces a plot with no line break
> plot([NaN,2,3,4,5]) produces a plot with no line
> 
> I know use of NaN's is not encouraged, and we have discussed it on this list. 
> But since they are sometimes unintended and unavoidable, I'm reporting the 
> behavior so people are not surprised when they get an empty plot.
> 
> Darren
This comes up often enough that it might be worth doing automatic 
masking of NaNs in the high-level argument processing wherever we are 
now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
this overhead, but now I think the overhead might be negligible in 
almost all cases. It looks like it would be on the order of 
milliseconds per high-level call, where by high-level call I mean plot, 
pcolor, quiver, etc. (either via pylab or Axes method).
Eric

It looks like the new transforms codebase does not support data that contains 
NaNs the way the old trunk did:
plot([1,2,NaN,4,5]) produces a plot with no line break
plot([NaN,2,3,4,5]) produces a plot with no line
I know use of NaN's is not encouraged, and we have discussed it on this list. 
But since they are sometimes unintended and unavoidable, I'm reporting the 
behavior so people are not surprised when they get an empty plot.
Darren

Michael Droettboom wrote:
> Eric Firing wrote:
>> 2) there is a positioning problem with the table part of table_demo.py.
> 
> I don't see this. (I must just be looking in the wrong place). Can you 
> be more specific?
The problem went away. I was pretty sure I had already deleted my old 
installation and build directory before the previous test, but maybe I 
missed something. With a fresh build and installation it is fine now.
Eric

Nils,
That's weird. I've cleared and rebuilt everything and I still don't see 
this problem on my install. (See my attached copy.)
Thanks for the info. Can you send your versions (Python, numpy etc.) 
and platform info? I don't really know what may be causing this difference.
Cheers,
Mike
Nils Wagner wrote:
> On 2008年1月09日 13:37:35 -0500
> Michael Droettboom <md...@st...> wrote:
>> Eric Firing wrote:
>>> Mike,
>>>
>>> In going through examples (on transforms branch immediately before 
>>> you made the switch), it looks like there are a couple of new bugs
>>> in those included by backend_driver.py:
>>>
>>> 1) legend_demo.py and legend_demo2.py make spurious black blocks, which
>>> go away when the plots are redrawn.
>>
>> This is now fixed in SVN.
>>
>>> 2) there is a positioning problem with the table part of table_demo.py.
>>
>> I don't see this. (I must just be looking in the wrong place). Can 
>> you be more specific?
>>
> Mike,
> 
> Please find attached the output of table_demo.py.
> 
> Cheers,
> 
> Nils
> 
> ------------------------------------------------------------------------
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Mike,
> 
> In going through examples (on transforms branch immediately before you 
> made the switch), it looks like there are a couple of new bugs
> in those included by backend_driver.py:
> 
> 1) legend_demo.py and legend_demo2.py make spurious black blocks, which
> go away when the plots are redrawn.
This is now fixed in SVN.
> 2) there is a positioning problem with the table part of table_demo.py.
I don't see this. (I must just be looking in the wrong place). Can you 
be more specific?
I also discovered a clipping bug that affects legends. I'm working on 
that now.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Now that the transforms branch has merged with the trunk, I'd like to 
resurrect namespace packages so that toolkits will work again when 
matplotlib is installed as an egg. As was discussed in a previous 
thread, all __init__.py files in the toolkit hierarchy must be empty 
(aside declare_namespace statement). Since lib/matplotlib/__init__.py 
contains a lot of important stuff, I think the path of least resistance 
is to move the toolkits out of lib/matplotlib and into a separate 
directory lib/mpl_toolkits. The semantics of importing a toolkit would 
have to change from
import matplotlib.toolkits.toolkit
to
import mpl_toolkit.toolkit.
Of course, all the toolkit __init__.py files would need to be emptied. 
In the case of basemap, this would be changing imports from
from matplotlib.toolkits.basemap import Basemap
to something like
from mpl_toolkits.basemap.api import Basemap
All the stuff now imported directly into __init__.py would go in api.py.
I've tried this in my local tree and it seems to work fine. Does this 
sound reasonable? If there's general agreement, I can make the 
necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Sorry -- I was too thick to get the reference. Maybe if you had 
included a cute picture of a kitten eating a cheeseburger or riding and 
invisible bicycle or something... This list needs more of those ;)
Cheers,
Mike
Tom Holroyd wrote:
> Sorry, I just don't like that word. And the "UR ..." was a lame
> reference to LOL Cats. :-) Sorry, sorry, I'll go away now.
> P.S. I love matplotlib.
> 
> On Tue, 2008年01月08日 at 22:53 +0100, Gael Varoquaux wrote:
>> On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
>>> I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
>>> however. Much of this change can be considered refactoring wrt to the 
>>> high-level public API. 
>> Refactoring is often defined (in test driven development) as reworking
>> the codebase given a complete set of tests that pass at the beginning,
>> and should pass at the end.
>>
>> My 2 cents,
>>
>> Gaël
> 
> Dr. Tom
> --
> This precept, however, give I to you, in parting, you fool: Where one
> can no longer love, there should one pass by! Thus spoke Zarathustra.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I find the usage of linestyle very _unconvenient_, since there are these 
two options - linestyle='--' and linestyle='dashed' - which are not 
exchangable.
I had some code where I initially used the Line2D class, so I had to use 
linestyle='--'. Now I changed my code to use a LineCollection. 
LineCollection doesn't work with linestyle='--', but requires 
linestyle='dashed' - and contrawise Line2D doesn't accept 
linestyle='dashed', but requires linestyle='--'.
Isn't it possible - and desirable - to unify the usage of linestyle ?
Manuel

Sorry, I just don't like that word. And the "UR ..." was a lame
reference to LOL Cats. :-) Sorry, sorry, I'll go away now.
P.S. I love matplotlib.
On Tue, 2008年01月08日 at 22:53 +0100, Gael Varoquaux wrote:
> On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
> > I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
> > however. Much of this change can be considered refactoring wrt to the 
> > high-level public API. 
> 
> Refactoring is often defined (in test driven development) as reworking
> the codebase given a complete set of tests that pass at the beginning,
> and should pass at the end.
> 
> My 2 cents,
> 
> Gaël
Dr. Tom
--
This precept, however, give I to you, in parting, you fool: Where one
can no longer love, there should one pass by! Thus spoke Zarathustra.

Thanks. I'll have a look at these tomorrow. It's actually nice to think I'll have some more eyes on this code soon... It's a lot of work keeping up with so many examples when the changes are so fundamental.
Cheers,
Mike

Mike,
In going through examples (on transforms branch immediately before you 
made the switch), it looks like there are a couple of new bugs
in those included by backend_driver.py:
1) legend_demo.py and legend_demo2.py make spurious black blocks, which
 go away when the plots are redrawn.
2) there is a positioning problem with the table part of table_demo.py.
Both of these are seen with the Agg or gtkagg backend; I have not
checked other backends.
Eric

Migrating to the new matplotlib codebase
========================================
Michael Droettboom has spent the last several months working on the
"transforms branch" of matplotlib, in which he rewrote from the ground
up the transformation infrastructure in matplotlib, which many found
unintuitive and hard to extend. In addition to a cleaner code base,
the reorganization allows you to define your own transformations and
projections (e.g. map projections) within matplotlib. He has merged his
work into the HEAD of the svn trunk, and this will be the basis for
future matplotlib releases.
If you are a svn user, we encourage you to continue using the trunk as
before, but with the understanding that you are now truly on the
bleeding edge. Michael has made sure all the examples still pass with
the new code base, so for the vast majority of you, I expect to see
few problems. But we need to get as many people as possible using the
new code base so we can find and fix the remaining problems. We have
take the svn code used in the last stable release in the 0.91 series,
and made it a maintenance branch so we can still fix bugs and support
people who are not ready to migrate to the new transformation
infrastructure but nonetheless need access to svn bug fixes.
Using the new code
==================
To check out the trunk with the latest transforms changes:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
If you already have a working copy of the trunk, your next "svn up" will
include the latest transforms changes.
Before installing, make sure you completely remove the old matplotlib
build and install directories, eg:
 > cd matplotlib
 > sudo rm -rf build
 > sudo rm -rf /usr/local/lib/python2.5/site-packages/matplotlib
 > sudo python setup.py install
Using the old svn code
======================
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
 matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x maintenance branch should be
merged into the trunk so they are fixed there as well. Svnmerge.py
makes this process rather straightforward, but you may also manually
merge if you prefer.
Merging bugfixes on the maint branch to the trunk using svnmerge.py
-------------------------------------------------------------------
Download svnmerge.py from here:
 http://www.orcaware.com/svn/wiki/Svnmerge.py
>From the working copy of the *trunk* (svnmerge.py always pulls *to*
the current working copy), so
 > svnmerge.py merge
to pull in changes from the maintenance branch. Manually resolve any
conflicts, if necessary, test them, and then commit with
 > svn commit -F svnmerge-commit-message.txt
(Note the above will stop working when the maintenance branch is
abandoned.)
API CHANGES in the new transformation infrastructure
====================================================
While Michael worked hard to keep the API mostly unchanged while
performing what has been called "open heart surgery on matplotlib",
there have been some changes, as discussed below.
The primary goal of these changes was to make it easier to
extend matplotlib to support new kinds of projections. This is
primarily an internal improvement, and the possible user-visible
changes it allows are yet to come.
These changes are detailed in the API_CHANGES document.