What about pulling all the plotting routines into a
> separate file that can be included by anyone who just
> wants the comfortable plotting commands without all the
> other namespace cluttering. pylab itself would then only
> contain lots of imports and all the namespace mangling.
I think this is a good idea, especially since is a natural way to do
it with the existing organization that shouldn't break much code. We
already have the two modules in place: matplotlib.pylab and pylab.
The former would just export the plotting symbols defined therein and
the latter would be the namespace aggregator. Thus pylab.__all__
would be just as it is with 0.71 (plotting, numerix, mlab,
matplotlib.dates symbols, matplotlib.ticker symbols, some colormapping
stuff) and matplotlib.pylab.__all__ would only be the plotting
commands.
Scripts which currently do
from pylab import *
would be unaffected.
There are some scripts which would be affected by these changes for
those who eschew 'import *'. If you are getting the DateFormatter
from pylab, you'll have to get it from matplotlib.dates instead.
Basically, this would primarily affect people who are using custom
tick locators or date locators/formatters. Of course,
matplotlib.pylab *could* continue to provide these, but that seems to
defeat the purpose of the change, which is to be more rigorous about
exported namespaces.
So the two questions are: 1) are people in favor of this change? and
2) if so, what should matplotlib.pylab export? Only symbols defined
therein? Or perhaps add a few for backward compatibility? Specifically
I'm wondering if matplotlib.pylab should continue to export: cm.jet,
cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and
*Formatter symbols from matplotlib.ticker and matplotlib.dates? I
don't suppose it's possible to "warn on import", eg warning
"matplotlib.pylab import of date2num is deprecated, please use
matplotlib.dates instead". One could write wrappers for this, I know,
but is there some import wizardry which supports this?
JDH
Don't know, whether it is a good idea to make a distinction between pylab and
matplotlib.pylab - It would be clearer to create a new module (maybe
matplotlib.plotting, matplotlib.pyplot or whatever) and move all routines
from pylab to that new module.
That would make clear: the term 'pylab' stands for the idea to create an
environment that is as similar as possible to matlab.
For the question what the new module should contain: only a small, clear-cut
set of routines. A regular module should only export what it defines itself.
Re-exporting blurs the modularity of the library and makes it harder to
understand.
Ciao,
Norbert
···
Am Montag, 24. Januar 2005 16:09 schrieb John Hunter:
> What about pulling all the plotting routines into a
> separate file that can be included by anyone who just
> wants the comfortable plotting commands without all the
> other namespace cluttering. pylab itself would then only
> contain lots of imports and all the namespace mangling.
I think this is a good idea, especially since is a natural way to do
it with the existing organization that shouldn't break much code. We
already have the two modules in place: matplotlib.pylab and pylab.
The former would just export the plotting symbols defined therein and
the latter would be the namespace aggregator.
--
_________________________________________Norbert Nemec
Bernhardstr. 2 ... D-93053 Regensburg
Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
eMail: <Norbert@...399...>
So the two questions are: 1) are people in favor of this change? and
I haven't given lengthy thought, but yes, I think it is probably a good
idea. The only counterargument is that something like making them available
in pylab is that it guards a bit against possible reorganization of the
modules and could potentially shield users against that. One view of pylab
is that it provides a more stable interface to what is underneath. If there
are items that are pretty fixed in their design, perhaps they belong (here
or in another related module)
2) if so, what should matplotlib.pylab export? Only symbols defined
therein? Or perhaps add a few for backward compatibility? Specifically
I'm wondering if matplotlib.pylab should continue to export: cm.jet,
cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and
*Formatter symbols from matplotlib.ticker and matplotlib.dates? I
don't suppose it's possible to "warn on import", eg warning
"matplotlib.pylab import of date2num is deprecated, please use
matplotlib.dates instead". One could write wrappers for this, I know,
but is there some import wizardry which supports this?
I think one could overload the import mechanism to handle this, but I'm
thinking that it is probably not worth the downside of messing with
the import mechanism.
Perry
···
On Jan 24, 2005, at 10:09 AM, John Hunter wrote: