I just removed the last vestiges of the numerix extension code layer. The conditional imports are gone from the extension code, the -D flags are gone from the compile, as is the _ns_ module naming scheme. This is a fairly major change, so please blow away your install and build dirs after updating to r3513 I also numpified axes.py, by far the biggest and most complicated module, and fixed all of the imports as we discussed in an earlier thread. One problem I ran into. With the proposed from matplotlib import lines # and friends there is a lot of possibility for name clashes. Eg, in some places we also have a variable names "lines", which isn't life threatening but certainly can lead to confusion and bugs. Or for module legend, we also have an Axes function.legend. I decided to go with a foolish consistency that was unambiguous: from matplotlib import artist as mpl_artist from matplotlib import agg as mpl_agg from matplotlib import axis as mpl_axis from matplotlib import cbook as mpl_cbook from matplotlib import collections as mpl_collections from matplotlib import colors as mpl_colors from matplotlib import contour as mpl_contour and then mpl_cbook.iterable # and so on Because the mpl_ prefix occurs nowhere else, we can easily change this to whatever we want with a single search replace. I also added a module mpl which simply imports all the modules, so API or pylab users can >>> from pylab import mpl or >>> from matplotlib import mpl and have all of the API in one place (mpl.dates, mpl.figure, mpl.ticker, etc...) -- nice with tab completion an online help in ipython when you aren't sure where to find something.... I was hoping we could use this in the matplotlib code itself. Eg if axes could import mpl, then we could replace the somewhat ugly mpl_cbook with the nice and pretty mpl.cbook, but there is the problem of recursive imports. Is there a way to do this with some python magic, so that one "mpl" API module could serve all of the modules? Something in the back of my mind is telling me there is something in EGGS with an api module..... Any ideas? JDH
John Hunter wrote: > from matplotlib import artist as mpl_artist > from matplotlib import agg as mpl_agg > from matplotlib import axis as mpl_axis > from matplotlib import cbook as mpl_cbook > from matplotlib import collections as mpl_collections > from matplotlib import colors as mpl_colors > from matplotlib import contour as mpl_contour might as well import matplotlib as mpl and use mpl.artist, etc.
On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <to...@ku...> wrote: > import matplotlib as mpl > > and use mpl.artist, etc. I don't think this will work in this form. artist is a module, and it is not imported simply by importing matplotlib In [1]: import matplotlib as mpl In [2]: mpl.artist ------------------------------------------------------------ Traceback (most recent call last): File "<ipython console>", line 1, in ? AttributeError: 'module' object has no attribute 'artist'
I think he means that the matplotlib/__init__.py file should be changed to that those things are imported. At 01:12 PM 7/13/2007, John Hunter wrote: >On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <to...@ku...> wrote: > > > import matplotlib as mpl > > > > and use mpl.artist, etc. > >I don't think this will work in this form. artist is a module, and it >is not imported simply by importing matplotlib > >In [1]: import matplotlib as mpl > >In [2]: mpl.artist >------------------------------------------------------------ >Traceback (most recent call last): > File "<ipython console>", line 1, in ? >AttributeError: 'module' object has no attribute 'artist' > >------------------------------------------------------------------------- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory ted...@jp...
On 7/13/07, Ted Drain <ted...@jp...> wrote: > I think he means that the matplotlib/__init__.py file should be > changed to that those things are imported. but if __init__.py imports axes, and axes import matplotlib, don't we still have the problem of recursive imports? JDH
Yes - it doesn't solve or address the recursive import problem. My impression was that Tom was making a user interface assertion that doing: import matplotlib as mpl would be simpler for people than doing: from matplotlib import mpl of course I could be complete wrong as well :) I think the basic idea is that if I want to use MPL, I should import it and go and I should not have to import a sub-module out of MPL as the main API. At 01:25 PM 7/13/2007, John Hunter wrote: >On 7/13/07, Ted Drain <ted...@jp...> wrote: > > I think he means that the matplotlib/__init__.py file should be > > changed to that those things are imported. > >but if __init__.py imports axes, and axes import matplotlib, don't we >still have the problem of recursive imports? > >JDH > >------------------------------------------------------------------------- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory ted...@jp...
Ted Drain wrote: > I think the basic idea is that if I want to use MPL, I should import > it and go and I should not have to import a sub-module out of MPL as > the main API. Yeah, about that, my typical usage is actually "from pylab import *". I guess I am unclear about the relationship between matplotlib and pylab. -- Tom Holroyd, Ph.D. "The fundamentally misconceived nature versus nurture debate should be abandoned: child development is inextricably both." -- Louann Brizendine
On Fri, Jul 13, 2007 at 03:06:45PM -0500, John Hunter wrote:
> Because the mpl_ prefix occurs nowhere else, we can easily change this
> to whatever we want with a single search replace.
I haven't sync'd with the repository yet so I can check this assertion:
h123063:~/src/matplotlib$ find . -name "*.py" | xargs grep mpl_ | wc
191 627 20498
These are mostly mpl_connect and mpl_disconnect, so not too bad.
The only other use of mpl_ is the following:
h123063:~/src/matplotlib$ find . -name "*.py" | xargs grep mpl_ | grep -v mpl_connect | grep -v mpl_disconnect
./examples/mpl_with_glade.py: self.widgets = gtk.glade.XML('mpl_with_glade.glade')
./lib/matplotlib/backends/backend_wx.py: - mpl_with_glade.py | N/A (2) | N/A (2) |
./OME/python/matplotlib/backends/backend_wx.py: - mpl_with_glade.py | N/A (2) | N/A (2) |
- Paul
John Hunter wrote: > On 7/13/07, Ted Drain <ted...@jp...> wrote: >> I think he means that the matplotlib/__init__.py file should be >> changed to that those things are imported. > > but if __init__.py imports axes, and axes import matplotlib, don't we > still have the problem of recursive imports? Yes, but that is not necessarily fatal. It depends on the order in which things are defined and imports are made: http://effbot.org/zone/import-confusion.htm Is there a significant performance penalty, however, in forcing every module to be imported every time any mpl script is run, regardless of whether the module is used in that script? Anyway, I *think* it is feasible to arrange matplotlib.__init__.py so that it imports all the modules, and then use import matplotlib as mpl ... mpl.cbook.is_iterable(x) ... both in scripts and within mpl modules. Whether this is the best approach is another question. Eric > > JDH > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Tom Holroyd (NIH/NIMH) [E] wrote: > > Ted Drain wrote: >> I think the basic idea is that if I want to use MPL, I should import >> it and go and I should not have to import a sub-module out of MPL as >> the main API. > > Yeah, about that, my typical usage is actually "from pylab import *". > I guess I am unclear about the relationship between matplotlib and pylab. > Tom, matplotlib is the object-oriented plotting library; pylab is a module within matplotlib that provides a matlab-style (state-machine) interface to the library. Eric
Eric Firing wrote: > Tom Holroyd (NIH/NIMH) [E] wrote: >> >> Ted Drain wrote: >>> I think the basic idea is that if I want to use MPL, I should import >>> it and go and I should not have to import a sub-module out of MPL as >>> the main API. >> >> Yeah, about that, my typical usage is actually "from pylab import *". >> I guess I am unclear about the relationship between matplotlib and pylab. >> > > Tom, > > matplotlib is the object-oriented plotting library; pylab is a module > within matplotlib that provides a matlab-style (state-machine) interface > to the library. > > Eric If I say >>> import matplotlib >>> help(matplotlib) (This is with 0.90.0 by the way) It basically gives me the help I'd expect for pylab. Oh, and it says "the" instead of "to". It's a little weird thinking of a library as the top level with the main interface as a module. I guess the interface is just another component of the library. Though when I >>> import pylab >>> help(pylab) I get what looks like help for numpy. Perhaps my installation is strange? -- Tom Holroyd, Ph.D. "The fundamentally misconceived nature versus nurture debate should be abandoned: child development is inextricably both." -- Louann Brizendine
Eric Firing wrote: > John Hunter wrote: >> On 7/13/07, Ted Drain <ted...@jp...> wrote: >>> I think he means that the matplotlib/__init__.py file should be >>> changed to that those things are imported. >> but if __init__.py imports axes, and axes import matplotlib, don't we >> still have the problem of recursive imports? > > Yes, but that is not necessarily fatal. It depends on the order in which > things are defined and imports are made: > > http://effbot.org/zone/import-confusion.htm > > Is there a significant performance penalty, however, in forcing every > module to be imported every time any mpl script is run, regardless of > whether the module is used in that script? > > Anyway, I *think* it is feasible to arrange matplotlib.__init__.py so > that it imports all the modules, and then use > > import matplotlib as mpl > ... mpl.cbook.is_iterable(x) ... > > both in scripts and within mpl modules. I have done a little experimentation, and I am pretty sure this will work. The problem I have run into so far is that in the initial orgy of importing, at the end of matplotlib/__init__, one has to be careful about the order so that kwdocd entries exist when they are needed. So, John, is this the direction you would like to go? It would mean that a long list of module imports at the top of each module would go away, replaced by the single "import matplotlib as mpl". This is simpler, but it removes the concise information about what modules a given module depends on. Eric > > Whether this is the best approach is another question. > > Eric >> JDH
John Hunter wrote: > I don't think this will work in this form. artist is a module, and it > is not imported simply by importing matplotlib > > In [1]: import matplotlib as mpl > > In [2]: mpl.artist however, this seems to work (though it looks perhaps a bit odd) >>> import matplotlib as mpl >>> import matplotlib.artist >>> mpl.artist <module 'matplotlib.artist' from '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/artist.pyc'> I do like this better -- names like mpl_*** rub me the wrong way. it looks like you really want a namespace -- and indeed you do! maybe the real solution is to have the matplotlib called "mpl" from the get go, like wxPython does: import wx wx.Whatever... I do wish that: >>> import matplotlib as mpl >>> import mpl.artist Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named mpl.artist worked. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Christopher Barker wrote: > John Hunter wrote: [...] > I do wish that: > >>>> import matplotlib as mpl >>>> import mpl.artist > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ImportError: No module named mpl.artist > > worked. The way I have it working now (on my machine, not in svn), when you import matplotlib as mpl You don't need to then import mpl.artist; it is already imported, ready for use. Eric > > -Chris > > >
Tom Holroyd (NIH/NIMH) [E] wrote: [...] > If I say > >>>> import matplotlib >>>> help(matplotlib) > > (This is with 0.90.0 by the way) > > It basically gives me the help I'd expect for pylab. Oh, and it says > "the" instead of "to". It's a little weird thinking of a library as the > top level with the main interface as a module. I guess the interface is > just another component of the library. Though when I > >>>> import pylab >>>> help(pylab) > > I get what looks like help for numpy. Perhaps my installation is strange? > No, it is not your installation. You have identified an area that needs work, after we settle on a possibly new import and namespace strategy. Eric
On 7/13/07, Eric Firing <ef...@ha...> wrote: > No, it is not your installation. You have identified an area that needs > work, after we settle on a possibly new import and namespace strategy. This is definitely something new -- help(pylab) used to display the rather extensive pylab doc string, which starts with in pylab.py: "" This is a matlab(TM) style interface to matplotlib. The following plotting commands are provided; some of these do not exist in matlab(TM) but have proven themselves to be useful nonetheless. The majority of them, however, have matlab analogs ...snip """ Are eggs doing something fishy here? This is a weird one. JDH
John Hunter wrote: > On 7/13/07, Eric Firing <ef...@ha...> wrote: > >> No, it is not your installation. You have identified an area that needs >> work, after we settle on a possibly new import and namespace strategy. > > This is definitely something new -- help(pylab) used to display the > rather extensive pylab doc string, which starts with in pylab.py: > > "" > This is a matlab(TM) style interface to matplotlib. > > The following plotting commands are provided; some of these do not > exist in matlab(TM) but have proven themselves to be useful > nonetheless. > The majority of them, however, have matlab analogs > ...snip > """ > > Are eggs doing something fishy here? This is a weird one. > JDH But it does it on linux, not using eggs. I couldn't figure it out--just assumed it had always done that, and I had never noticed. Still, the matplotlib/__init__.py docstring could be changed to make clear the distinction between mpl and the pylab interface. Instead, it talks only about the latter: efiring@manini:~/programs/py/mpl/matplotlib_units/lib/matplotlib$ head __init__.py """ This is a matlab(TM) style functional interface the matplotlib. The following matlab(TM) compatible commands are provided by >>> from pylab import * Plotting commands axes - Create a new axes Eric
Tom Holroyd (NIH/NIMH) [E] wrote: [...] > If I say > >>>> import matplotlib >>>> help(matplotlib) > > (This is with 0.90.0 by the way) > > It basically gives me the help I'd expect for pylab. Oh, and it says > "the" instead of "to". It's a little weird thinking of a library as the > top level with the main interface as a module. I guess the interface is > just another component of the library. Though when I > >>>> import pylab >>>> help(pylab) > > I get what looks like help for numpy. Perhaps my installation is strange? > I have fixed this. The problem was that when you import pylab, it imports a stub "pylab.py" from site-packages, which in turn imports everything from matplotlib/pylab.py. The matplotlib.pylab docstring does not get transferred to the newly loaded pylab module, however. The solution was to do that transfer explicitly in the pylab.py stub. I also made slight tweaks to the pylab.py and matplotlib.py docstrings to try to clarify the pylab-matplotlib relationship. The matplotlib docstring still blathers on about pylab functions, however; I suspect we should change this to something more unique and helpful, such as a directory of matplotlib submodules and/or an intro to the useful things in matplotlib.__init__.py like rcParams. Eric
On 7/15/07, Eric Firing <ef...@ha...> wrote: \> docstring still blathers on about pylab functions, however; I suspect we > should change this to something more unique and helpful, such as a > directory of matplotlib submodules and/or an intro to the useful things > in matplotlib.__init__.py like rcParams. Verg good idea -- are you volunteering? :-) JDH PS: in other news, I find it ironic that the gmail spell checker, which underlines words it doesn't recognize with a red line (eg rcParams), doesn't recognize the word "gmail"
John Hunter wrote: > On 7/15/07, Eric Firing <ef...@ha...> wrote: > \> docstring still blathers on about pylab functions, however; I suspect we >> should change this to something more unique and helpful, such as a >> directory of matplotlib submodules and/or an intro to the useful things >> in matplotlib.__init__.py like rcParams. > > Verg good idea -- are you volunteering? :-) OK. Eric
On Friday 13 July 2007 06:29:59 pm Eric Firing wrote: > Eric Firing wrote: > > John Hunter wrote: > >> On 7/13/07, Ted Drain <ted...@jp...> wrote: > >>> I think he means that the matplotlib/__init__.py file should be > >>> changed to that those things are imported. > >> > >> but if __init__.py imports axes, and axes import matplotlib, don't we > >> still have the problem of recursive imports? > > > > Yes, but that is not necessarily fatal. It depends on the order in which > > things are defined and imports are made: > > > > http://effbot.org/zone/import-confusion.htm > > > > Is there a significant performance penalty, however, in forcing every > > module to be imported every time any mpl script is run, regardless of > > whether the module is used in that script? > > > > Anyway, I *think* it is feasible to arrange matplotlib.__init__.py so > > that it imports all the modules, and then use > > > > import matplotlib as mpl > > ... mpl.cbook.is_iterable(x) ... > > > > both in scripts and within mpl modules. > > I have done a little experimentation, and I am pretty sure this will > work. The problem I have run into so far is that in the initial orgy of > importing, at the end of matplotlib/__init__, one has to be careful > about the order so that kwdocd entries exist when they are needed. > > So, John, is this the direction you would like to go? It would mean > that a long list of module imports at the top of each module would go > away, replaced by the single "import matplotlib as mpl". This is > simpler, but it removes the concise information about what modules a > given module depends on. I just discovered this in axes.py: # import a bunch of matplotlib modules into a single namespace mpl = matplotlib.Importer("""artist, agg, axis, cbook, collections, colors, contour, dates, font_manager, image, legend, lines, mlab, cm, patches, quiver, table, text, ticker, transforms""") This seems a little too cute too me, no offense intended to the clever author. Why do we need a single namespace? It seems unadvisable. There is additional overhead with namespace lookups: running numpy.arange(10) a million times takes 15% longer than arange(10). I would have thought it best to do more of "from w import x, y, z" Darren
On 7/16/07, Darren Dale <dd...@co...> wrote: > This seems a little too cute too me, no offense intended to the clever author. > Why do we need a single namespace? It seems unadvisable. There is additional > overhead with namespace lookups: running numpy.arange(10) a million times > takes 15% longer than arange(10). I would have thought it best to do more > of "from w import x, y, z" Eric Firing and I discussed this extensively off list over the weekend -- we tried a bunch of things (eg the Importer and Namespace classes) and I was using svn as a testing lab, fully aware that this may not be the right final solution, but the code worked and was easily changed. In the end, we decided not to do it, favoring instead the simple from matplotlib import cbook # unlikely clash, use module name as is from matplotlib import lines as mlines # add m prefix to avoid likely clash I just haven't fixed the code yet. JDH
Darren Dale wrote:
[...]
> Why do we need a single namespace? It seems unadvisable. There is additional
> overhead with namespace lookups: running numpy.arange(10) a million times
> takes 15% longer than arange(10). I would have thought it best to do more
> of "from w import x, y, z"
I have indeed been concerned about this performance aspect, and it was a
consideration in dropping the mpl namespace. John's original
prescription ("import matplotlib.lines as lines") was very close to what
we eventually converged on ("from matplotlib import lines as mlines"),
but we will still be doing more namespace lookups now than we were
before numpification. The advantage is fewer clashes and clearer code;
I won't have to rack my brains to try to remember (or pause to go to the
top of the file to look) where a given function came from; the
disadvantages are the extra lookups, and the increased difficulty in
keeping code compact, concise, and nicely formatted. I have come around
to the view that for the most part, the advantages outweigh the
disadvantages, and we have a reasonable compromise; but as John
mentioned in our weekend discussions, we might want to make
exceptions--so long as we don't end up with more exceptions than
rule-followers. Maybe the thing to do is to make exceptions sparingly
where it looks like there is a substantial benefit, either for
performance or for readability. In practice, I expect that the penalty
for the extra lookups will be negligible in almost every case.
Eric