Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
I'll fess up that I added the setuptools namespace support for the toolkits. Keep in mind I did this a LONG time ago, and as implied below the docs were sketchy. It did work at the time, but I honestly have not had basemap installed in a while to see the breakage. Charlie On 2/9/07, Andrew Straw <[EMAIL PROTECTED]> wrote: > It looks like we're on the hook for some bugs associated with our use of > setuptools... I'm forwarding an email from the distutils-sig. > > The short of it is that Phillip Eby suggests we move matplotlib.toolkits > to matplotlib_toolkits to save ourselves some grief. This does seem > easier than the apparent alternative -- moving everything out of > matplotlib/__init__.py. > > -Andrew > > > -- Forwarded message -- > From: "Phillip J. Eby" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], distutils-sig@python.org > Date: Fri, 09 Feb 2007 19:20:31 -0500 > Subject: Re: [Distutils] Confusion about the effect of eggs on import > At 05:30 PM 2/9/2007 -0600, [EMAIL PROTECTED] wrote: > >(I'm sending this to distutils because I have this vague notion that the > >problem might have something to do with setuptools or eggs on sys.path.) > > Their mere presence on sys.path doesn't do anything, if you're not > importing pkg_resources or importing anything from inside the eggs. > > However, matplotlib imports pkg_resources and is a (broken) namespace package. > > > >We have a weird issue trying to import matplotlib at work. > > I investigated a little, and here's what's happening. Matplotlib declares > 'matplotlib.toolkits' as a namespace package, but you can't make a child > package a namespace package without the parent being one too. A namespace > package combines all packages on sys.path with the same name into a single > package. > > So here's what's happening. When setuptools is on sys.path, then importing > matplotlib causes it to declare its namespace, which merges all copies of > matplotlib on sys.path into a single super-package -- and invokes all the > __init__.py's. > > When setuptools is not on sys.path, the attempt to declare the namespace > fails (it's wrapped in a try/except in matplotlib/__init__.py), so nothing > else happens. > > There are, I think, two problems here. One, is that setuptools shouldn't > be executing multiple __init__.py's for a package, but for backward > compatibility reasons this isn't being dropped until 0.7a1. Two, is that > setuptools currently allows you to declare a child namespace package (like > 'matplotlib.toolkits') without explicitly declaring the parent to be a > namespace package. So, sometimes people declare a subpackage without > realizing the parent will also have to be treated as a namespace package. > > As a result, they end up thinking that they can include initialization code > in the parent package, when in fact there are many circumstances where it > simply won't work. In this case, matplotlib/__init__.py contains > executable code, which is a no-no for a namespace package. > > My suggestion would be that matplotlib use a matplotlib_toolkits namespace > package, rather than attempting to keep matplotlib.toolkits, since it > appears they are relying on a substantial amount of code living in the > __init__.py. > > In short, the problem is a matplotlib bug, but in fairness it's probably > due to the sketchy documentation surrounding the proper care and feeding of > namespace packages, coupled with the implicit declaration of namespace > packages. All of the problems are explained in the setuptools > documentation, but unfortunately that's not the same as anybody being able > to figure out that the problems will apply to THEM. ;) > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On 2/9/07, Andrew Straw <[EMAIL PROTECTED]> wrote: > It looks like we're on the hook for some bugs associated with our use of > setuptools... I'm forwarding an email from the distutils-sig. > The short of it is that Phillip Eby suggests we move matplotlib.toolkits > to matplotlib_toolkits to save ourselves some grief. This does seem > easier than the apparent alternative -- moving everything out of > matplotlib/__init__.py. I could go either way -- we are going to break a lot of code no matter which way we do it. Ironically, and via a circuitous path, this is ultimately my problem. The problem Phil is discussing was raised by Skip on the distutils list. Skip works with me and is trying to diagnose an MPL install problem I encountered at work yesterday and asked for his input on. I am inclined to consider ripping out the __init__ stuff into a "config" module or something like that. The reason is that every time someone wants to use matplotlib as a library, eg to import a single function from matplotlib.cbook, they have to pay for the entire __init__load including the rc parse, even though cbook doesn' use anything else from the rest of matplotlib. It only depends on the standard library. So there is at least one additional reason to move the stuff from __init__ out. I also like the ability to use eggs to have mpl namespace packages, eg toolkits. So if ease-of-implementation is the only argument against ripping out the __init__ stuff I don't find it compelling (I'll be happy to do it) but if there are other reasons to leave __init__ as is let's hear them. JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote: > I am inclined to consider ripping out the __init__ stuff into a > "config" module or something like that. If my understanding is right, enthought does this with an "api" module. It might be worth going in the same direction. My 2 cents, Gaël -- Gael Varoquaux, Groupe d'optique atomique, Laboratoire Charles Fabry de l'Institut d'Optique Campus Polytechnique, RD 128 91127 Palaiseau cedex FRANCE NEW Phone number Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01 Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On 2/11/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote: > > I am inclined to consider ripping out the __init__ stuff into a > > "config" module or something like that. > > If my understanding is right, enthought does this with an "api" module. > It might be worth going in the same direction. > And for what it's worth this is also the direction nipy is taking, having an api.py in each package. Tim > My 2 cents, > > Gaël > > -- > Gael Varoquaux, > Groupe d'optique atomique, > Laboratoire Charles Fabry de l'Institut d'Optique > Campus Polytechnique, RD 128 > 91127 Palaiseau cedex FRANCE > NEW Phone number > Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01 > Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62 > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On 2/10/07, Tim Leslie <[EMAIL PROTECTED]> wrote: > And for what it's worth this is also the direction nipy is taking, > having an api.py in each package. I don't have a problem with this if it makes sense to other people and helps with consistency across packages, but I don't find the mnemonic particularly clear. Eg from matplotlib.config import rc, verbose makes more sense to me than from matplotlib.api import rc, verbose since I consider these (and most other stuff in __init__) to be part of the configuration, and a lot of stuff that doesn't live there (Figure, Axes, Line2D) to be part of the API. What is the enthought/nipy rationale for calling it api? JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On 2/11/07, John Hunter <[EMAIL PROTECTED]> wrote: > On 2/10/07, Tim Leslie <[EMAIL PROTECTED]> wrote: > > > And for what it's worth this is also the direction nipy is taking, > > having an api.py in each package. > > I don't have a problem with this if it makes sense to other people and > helps with consistency across packages, but I don't find the mnemonic > particularly clear. Eg > > from matplotlib.config import rc, verbose > > makes more sense to me than > > from matplotlib.api import rc, verbose > > since I consider these (and most other stuff in __init__) to be part > of the configuration, and a lot of stuff that doesn't live there > (Figure, Axes, Line2D) to be part of the API. What is the > enthought/nipy rationale for calling it api? > Sorry, I think I might have given the wrong impression. Our use of an api.py is for having a single location to import classes equivalent to Figure, Axes, etc from. Your suggestion of having a matplotlib.config for things like rc and verbose makes a lot of sense I think. Tim > JDH > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: [Distutils] Confusion about the effect of eggs on import]
On Sun, Feb 11, 2007 at 01:32:45AM +1100, Tim Leslie wrote: > Sorry, I think I might have given the wrong impression. Our use of an > api.py is for having a single location to import classes equivalent to > Figure, Axes, etc from. Your suggestion of having a matplotlib.config > for things like rc and verbose makes a lot of sense I think. Same missunderstanding here. Gaël - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] axes.hold: False causes unexpected behaviour
Hello, just thought I should report two unexpected behaviours, which took me a while to pinpoint: 1) errorbar() plots the points but not the errorbars if axes.hold==False for those axes (in my case, due to it being set to False in rcParams) 2) when axes.hold is False, (again either set locally for the current axes, or globally in rcParams), setting logscale _before_ calling bar() raises a ValueError: ValueError: Cannot set nonpositive limits with log transform Setting it to logscale _after_ calling bar() prevents the error. Setting axes.hold to True prevents the error in either case, even when setting logscale _before_ calling bar(). I fear this behaviour may be related to the couple of lines dealing with "holdstate" I submitted as part of a patch last year to axes.bar I think I may just set axes.hold back to the default True in my rcParams, since it seems that's what most people use and test with. But, it might be worthwhile to sort out any unintended behaviours when a user decides to set their rcParams['axes.hold']=False. Cheers, Martin - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes.hold: False causes unexpected behaviour
I forgot to mention, I'm running 0.87.7 in windows with WxAgg. Martin Martin Spacek wrote: > Hello, just thought I should report two unexpected behaviours, which > took me a while to pinpoint: > > 1) errorbar() plots the points but not the errorbars if axes.hold==False > for those axes (in my case, due to it being set to False in rcParams) > > 2) when axes.hold is False, (again either set locally for the current > axes, or globally in rcParams), setting logscale _before_ calling bar() > raises a ValueError: > > ValueError: Cannot set nonpositive limits with log transform > > Setting it to logscale _after_ calling bar() prevents the error. Setting > axes.hold to True prevents the error in either case, even when setting > logscale _before_ calling bar(). I fear this behaviour may be related to > the couple of lines dealing with "holdstate" I submitted as part of a > patch last year to axes.bar > > I think I may just set axes.hold back to the default True in my > rcParams, since it seems that's what most people use and test with. But, > it might be worthwhile to sort out any unintended behaviours when a user > decides to set their rcParams['axes.hold']=False. > > Cheers, > > Martin > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
