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] <tomh@...234...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Ted Drain Jet Propulsion Laboratory ted.drain@...179...
but if __init__.py imports axes, and axes import matplotlib, don't we
still have the problem of recursive imports?
JDH
···
On 7/13/07, Ted Drain <ted.drain@...179...> wrote:
I think he means that the matplotlib/__init__.py file should be
changed to that those things are imported.
John Hunter 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
···
On 7/13/07, Ted Drain <ted.drain@...179...> wrote:
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Eric Firing wrote:
John Hunter 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
···
On 7/13/07, Ted Drain <ted.drain@...179...> wrote:
Whether this is the best approach is another question.
Eric
JDH
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 Friday 13 July 2007 06:29:59 pm Eric Firing wrote:
Eric Firing wrote:
> John Hunter wrote:
>> On 7/13/07, Ted Drain <ted.drain@...179...> 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 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
···
On 7/16/07, Darren Dale <dd55@...143...> 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"
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