matplotlib-users Mailing List for matplotlib

As a protanope, and knowing that lots of folks with interest in graphics 
frequent this newsgroup, I thought I'd call everyone's attention to the 
article entitled "The End of the Rainbow? Color Schemes for Improved 
Data Graphics" which appeared in the 5 October 2004 issue of the 
American Geophysical Union's weekly newsmagazine EOS.  A Web site with 
the sample color schemes and a copy of the article is at 
http://geography.uoregon.edu/datagraphics/

On Jan 24, 2005, at 10:09 AM, John Hunter wrote:
> 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

Hi folks, I've noticed that zooming on the text won't make the text any 
larger, and some other instances like sub-axes share the problem too. And it 
is not the default zoom behavior people usually expect. Any solution to 
that?

Bao 

Hi a quick question:

- how do I write a label like this:

ylabel("$\sigma_{\rm{R}} / \sigma_e$")

to have: sigma_R / sigma_e with the R in \rm mode ?

At the moment it does not seem to work..

thanks for any help there.

[Is there any exhaustive list of what we can do in latex-like mode ?
I am for example looking for different ways to include ''spaces'']

Eric

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

Am Montag, 24. Januar 2005 16:09 schrieb John Hunter:
> >>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
>
>     Norbert> What about pulling all the plotting routines into a
>     Norbert> separate file that can be included by anyone who just
>     Norbert> wants the comfortable plotting commands without all the
>     Norbert> other namespace cluttering. pylab itself would then only
>     Norbert> 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.

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

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> What about pulling all the plotting routines into a
    Norbert> separate file that can be included by anyone who just
    Norbert> wants the comfortable plotting commands without all the
    Norbert> other namespace cluttering. pylab itself would then only
    Norbert> 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