[matplotlib-devel] Unconvenient usage of linestyle
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] moving to the transforms branch
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] resurrecting namespace packages
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/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] demo bugs
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] demo bugs
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 Wed, 09 Jan 2008 13:37:35 -0500 Michael Droettboom <[EMAIL PROTECTED]> 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 <>- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] demo bugs
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] NaN support
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] NaN support
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] NaN support
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 > Matplotlib-devel@lists.sourceforge.net > 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] NaN support
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 >> Matplotlib-devel@lists.sourceforge.net >> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] NaN support
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 > >> Matplotlib-devel@lists.sourceforge.net > >> 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 [EMAIL PROTECTED] office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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 >Matplotlib-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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 >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] > > > > - > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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/PSD1Email : [EMAIL PROTECTED]
325 BroadwayOffice : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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. - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] resurrecting namespace packages
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 > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
