matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
> I've been thinking a bit about rcParams and validation. It looks like values 
> are currently only validated when matplolibrc is read, during the call to 
> rc_params. What if we define a new class (RcParams), derived from dict, which 
> has as an attribute, a dict, called validate. We could override __setitem__ 
> such that
> 
> rcParams['font.size'] = 12
> 
> validates the value 12 by first calling validate_float, which is referenced in 
> the validate attribute:
> 
> def __setitem__(self, i='font.size', val=12)
> try:
> self.validate[i](val)
> dict.__setitem__(self, i, val)
> except KeyError:
> raise (or warning), bad value
> 
> the validation dict and default properties would be populated during the 
> initial call to rc_params(), when the defaultParams dict is interpretted. 
> Thereafter, any attempt to set a parameter, either directly using 
> rcParams[i]=j or indirectly using rc(), will benefit from validation. The 
> behavior would otherwise be unchanged, I think. Any comments or objections?
> 
I agree with John that the basic idea of validating rc keys and values 
regardless of whether they are set directly or via rc() is an important 
improvement to make. I think I understand the general idea of your 
proposed implementation. It looks like it could be done quite quickly 
and easily with no disruption elsewhere in the code. Alternative 
approaches that have been mentioned in the past involve properties or 
traits; but your proposed implementation may actually be cleaner, 
simpler, and more maintainable for present purposes. Have you compared 
alternatives? Have you looked at examples/rc_traits.py? (Or did you 
write it? I don't recall for sure, but I think John wrote it after one 
of our earlier discussions of traits/properties/neither.)
Eric

On 7/16/07, Darren Dale <dd...@co...> wrote:
> the validation dict and default properties would be populated during the
> initial call to rc_params(), when the defaultParams dict is interpretted.
> Thereafter, any attempt to set a parameter, either directly using
> rcParams[i]=j or indirectly using rc(), will benefit from validation. The
> behavior would otherwise be unchanged, I think. Any comments or objections?
This is a good idea, and it is also a good idea to validate the key.
I have wasted significant time before trying to track down a "bug"
when I thought usetex wasn't being enabled when all I had done was
mistype the rc key. I suggest a set of valid keys for fast lookup.
JDH

I've been thinking a bit about rcParams and validation. It looks like values 
are currently only validated when matplolibrc is read, during the call to 
rc_params. What if we define a new class (RcParams), derived from dict, which 
has as an attribute, a dict, called validate. We could override __setitem__ 
such that
rcParams['font.size'] = 12
validates the value 12 by first calling validate_float, which is referenced in 
the validate attribute:
 def __setitem__(self, i='font.size', val=12)
 try:
 self.validate[i](val)
 dict.__setitem__(self, i, val)
 except KeyError:
 raise (or warning), bad value
the validation dict and default properties would be populated during the 
initial call to rc_params(), when the defaultParams dict is interpretted. 
Thereafter, any attempt to set a parameter, either directly using 
rcParams[i]=j or indirectly using rc(), will benefit from validation. The 
behavior would otherwise be unchanged, I think. Any comments or objections?
Darren

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

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

John Hunter wrote:
> That or we simply adopt the TeX standard
+1 TeX is widely used and well documented -- why have something almost 
the same?
though I still think the real solution is to sue TeX itself to do the 
typesetting. not the way we do now, but:
Parsing the DVI and laying out stuff that way -- so it's scalable, and 
has fewer dependencies.
Including the fonts required (STIX again -- maybe it will really happen 
eventually)
Occasionally someone pops up with plan to make an embeddable TeX engine, 
which is what we really want--maybe some day.
-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...

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, Edin Salkovic <edi...@gm...> wrote:
> You use it like this (notice no backslashes):
> >>> from matplotlib._mathtext_data import tex2uni
> >>> unichr(tex2uni['int'])
> u'\u222b'
> >>> unichr(tex2uni['sum'])
> u'\u2211'
That's a rather good solution, as it avoids duplication, and is
friendly to dumb terminals and developers <wink>. You might simply
define some constants at the ticker module level for efficient reuse,
eg
usumchar = unichr(tex2uni['sum'])
etc...

On Monday 16 July 2007 02:32:30 pm John Hunter wrote:
> On 7/16/07, Michael Droettboom <md...@st...> wrote:
> > I'm working on some improvements to the mathtext engine on a branch.
> > Feel free to join in if curious, but I expect to break lots of things as
> > I go.
> >
> > https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathte
> >xt_mgd/
> >
> > I've collected a bunch of math expressions from the source tree for use
> > in regression testing. If you have any math strings of your own that
> > you want to make sure I don't break, please send them to me (probably
> > should be off-list to conserve noise).
> >
> > Here's the preliminary TODO list I'm working with in no particular order
> > (compiled from the TODO list in mathtext.py and the list of improvements
> > in mathtext2.py):
> >
> > 1. Deal with nested sub/superscripts, such as $x_i_j,ドル equivalent to
> > $x_{i_j}$
>
> Hmm, I thought that already worked -- it's been a long time since I
> touched that code. What is the problem here?
I think $x_i_j$ is ambiguous. Maybe it is best to stick to Knuth-approved 
syntax.
> > 2. Make the font change tags (\cal, \tt, \rm etc.) behave more like TeX,
> > e.g. use ${\rm sin}$ instead of $\rm{sin}$
Would it be possible to include the latex equivalents, like \textrm{} (its not 
{\textrm ...}), \texttt{}, \textit{}... ? They are more familiar to some of 
us (like latex's \frac{1}{2} is more familiar than tex's {1\over 2}). 
> > 3. Support roman function names, e.g. $\sin$ as a shortcut for ${\rm
> > sin}$ 4. Implement \frac
> > 5. Other layout commands, like large \sqrt (I suspect there's a very
> > large list of these things and they will have to be prioritized.)
>
> You will probably want to implement some primitive drawing in the
> ft2font pixel buffer, to support things like a \frac bar (\frac would
> be nice BTW)
Is mpl's mathtext guided by the algorithms published in "Computers and 
Typesetting, TeX: The Program"? 
> > 6. Support kerning (probably best put off until we have good fonts with
> > kerning information to use, e.g. STIX fonts)
>
> Ha, STIX, never made a deadline they could keep. Given their response
> to Eric's inquiry, we could be waiting quite a while.
They claim their website will be updated the week of July 9. They don't 
indicate what year.
> > (1 and 2 are already implemented in the branch.)
> >
> > I don't want to start a long thread about all the desired features for
> > mathtext -- I'm sure there are lots of them. There will need to be some
>
> How about a short one :-) I think one of the most important
> enhancements will be to support embedded mathtext expressions, eg
>
> r'some text $\sigma=1$ some more text'
>
> Currently we have to do something like
>
> r'$\rm{some text\ }\sigma=1\rm{\ some more text}$'
I agree, this is sorely lacking.
> which is pretty bad. This might require some changes to how mathtext
> is identified -- the presence of an even number of dollar signs is
> probably sufficient, but in some corner cases might give the wrong
> results, requiring a flag to overrride, etc. THat or we simply adopt
> the TeX standard and require all literal $ to be quoted. THe latter
> wil break some code but is probably better than anything else.
I think we should stick to the (La)TeX standard. The algorithms are available, 
stable (when was the last time Donald Knuth had to fix a bug in TeX?), and 
the syntax is familiar. 

On 7/16/07, Michael Droettboom <md...@st...> wrote:
> 1. Deal with nested sub/superscripts, such as $x_i_j,ドル equivalent to
> $x_{i_j}$
> 2. Make the font change tags (\cal, \tt, \rm etc.) behave more like TeX,
> In general, is the goal with mathtext to become as TeX-compatible as
> possible (for some subset of standard TeX math syntax?) The reason I
> ask is, (1) above is not valid LaTeX and raises the error "Double
> subscript". Task (2) will break backward compatibility with existing
> matplotlib plots. In the long run, maintaining two codebases or two
> separate paths through the same codebase probably won't scale.
Sorry I didn't address these on the first pass
Maximum compatibility with LaTeX is definitely the goal, within
reason. By that I mean, if we do something different and can fix it,
we should. I don't mean we should try and support everything that
LaTeX does, at least not this month <wink>
As for 1), the double subscript error, I thought it worked in TeX and
if it doesn't we should not support it. My comment in the TODO list
may have simply reflected this ignorance.
As for 2, the font syntax, we need not break existing mpl code,
because both \rm{text} and {\rm text} work in latex. We'll just be
adding support for the 2nd idiom.
JDH

T24gNy8xNi8wNywgTWljaGFlbCBEcm9ldHRib29tIDxtZHJvZUBzdHNjaS5lZHU+IHdyb3RlOgo+
IEFzIGZvciBVbmljb2RlIGxpdGVyYWxzIGluIFB5dGhvbiBzb3VyY2UsIHRoZXJlIGlzIGEgdGhp
cmQgb3B0aW9uLCBvdGhlcgo+IHRoYW4gdSdceGQ3JyBvciAnw5cnLiAgUHl0aG9uIHdpbGwgbGV0
IHlvdSBkbyB1IlxOe01VTFRJUExJQ0FUSU9OIFNJR059IiwKPiB3aGljaCBtZWFucyB5b3UgZG9u
J3QgaGF2ZSB0byByZW1lbWJlciB3aGF0IFx4ZDcgaXMuICBGb3Igc2luZ2xlCj4gY2hhcmFjdGVy
cyBsaWtlIHRoaXMsIEkgZG9uJ3Qgc2VlIG11Y2ggYWR2YW50YWdlICh5b3UgY2FuIGp1c3QgbmFt
ZSB0aGUKPiB2YXJpYWJsZSBzb21ldGhpbmcgb2J2aW91cyksIGJ1dCBmb3IgbG9uZ2VyIHN0cmlu
Z3Mgd2l0aCBlbWJlZGRlZAo+IHVuaWNvZGUgY2hhcmFjdGVycyAobGlrZSBkb2NzdHJpbmdzKSwg
dGhpcyBtaWdodCBiZSBzb21ldGhpbmcgdG8gY29uc2lkZXIuCgpUaGVyZSdzIGFsc28gYSBUZVgg
LT4gInVuaWNvZGUgaW50ZWdlciByZXByZXNlbnRhdGlvbiIgZGljdCBpbgpfbWF0aHRleHRfZGF0
YS5weS4gIEl0J3MgY2FsbGVkIHRleDJ1bmkuCgpZb3UgdXNlIGl0IGxpa2UgdGhpcyAobm90aWNl
IG5vIGJhY2tzbGFzaGVzKToKPj4+IGZyb20gbWF0cGxvdGxpYi5fbWF0aHRleHRfZGF0YSBpbXBv
cnQgdGV4MnVuaQo+Pj4gdW5pY2hyKHRleDJ1bmlbJ2ludCddKQp1J1x1MjIyYicKPj4+IHVuaWNo
cih0ZXgydW5pWydzdW0nXSkKdSdcdTIyMTEnCgpDaGVlcnMsCkVkaW4K

On 7/16/07, Andrew Straw <str...@as...> wrote:
> It looks like Edin made setuptools required in svn, which I just
> reverted. Edin -- why? I'm a fan of setuptools, but I don't think we
> should require a prerequisite that isn't necessary. Of course, if the
> developers decide we want to require setuptools, I'm happy to support
> the change, but it should probably have some kind of consensus.
I apologize for creating the fuss, it was a stupid mistake (I
overlooked the fact that we require setuptools only for Python 2.3).
> Edin, if you want to use setuptools for your own installations, you can
> do, from the command line
>
> python -c "import setuptools; execfile('setup.py')" install
Thanks for the tip.
Best,
Edin

John Hunter wrote:
> On 7/16/07, Michael Droettboom <md...@st...> wrote:
>> I'm working on some improvements to the mathtext engine on a branch.
>> Feel free to join in if curious, but I expect to break lots of things as
>> I go.
>>
>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/ 
>>
>>
>> I've collected a bunch of math expressions from the source tree for use
>> in regression testing. If you have any math strings of your own that
>> you want to make sure I don't break, please send them to me (probably
>> should be off-list to conserve noise).
>>
>> Here's the preliminary TODO list I'm working with in no particular order
>> (compiled from the TODO list in mathtext.py and the list of improvements
>> in mathtext2.py):
>>
>> 1. Deal with nested sub/superscripts, such as $x_i_j,ドル equivalent to
>> $x_{i_j}$
>
> Hmm, I thought that already worked -- it's been a long time since I
> touched that code. What is the problem here?
The j is the same size as the i, because its font size is (somehow) 
determined as if it were attached to the x. My fix was to make '_' be 
an infix operator that's right associative. That makes $x_i_j$ parse 
just like $x_{i_j},ドル and like how LaTeX appears to behave.
> How about a short one :-) I think one of the most important
> enhancements will be to support embedded mathtext expressions, eg
>
> r'some text $\sigma=1$ some more text'
>
> Currently we have to do something like
>
> r'$\rm{some text\ }\sigma=1\rm{\ some more text}$'
>
> which is pretty bad.
I'll add that to the list.
Cheers,
Mike

On 7/16/07, Michael Droettboom <md...@st...> wrote:
> I'm working on some improvements to the mathtext engine on a branch.
> Feel free to join in if curious, but I expect to break lots of things as
> I go.
>
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/
>
> I've collected a bunch of math expressions from the source tree for use
> in regression testing. If you have any math strings of your own that
> you want to make sure I don't break, please send them to me (probably
> should be off-list to conserve noise).
>
> Here's the preliminary TODO list I'm working with in no particular order
> (compiled from the TODO list in mathtext.py and the list of improvements
> in mathtext2.py):
>
> 1. Deal with nested sub/superscripts, such as $x_i_j,ドル equivalent to
> $x_{i_j}$
Hmm, I thought that already worked -- it's been a long time since I
touched that code. What is the problem here?
> 2. Make the font change tags (\cal, \tt, \rm etc.) behave more like TeX,
> e.g. use ${\rm sin}$ instead of $\rm{sin}$
> 3. Support roman function names, e.g. $\sin$ as a shortcut for ${\rm sin}$
> 4. Implement \frac
> 5. Other layout commands, like large \sqrt (I suspect there's a very
> large list of these things and they will have to be prioritized.)
You will probably want to implement some primitive drawing in the
ft2font pixel buffer, to support things like a \frac bar (\frac would
be nice BTW)
> 6. Support kerning (probably best put off until we have good fonts with
> kerning information to use, e.g. STIX fonts)
Ha, STIX, never made a deadline they could keep. Given their response
to Eric's inquiry, we could be waiting quite a while.
> (1 and 2 are already implemented in the branch.)
>
> I don't want to start a long thread about all the desired features for
> mathtext -- I'm sure there are lots of them. There will need to be some
How about a short one :-) I think one of the most important
enhancements will be to support embedded mathtext expressions, eg
 r'some text $\sigma=1$ some more text'
Currently we have to do something like
 r'$\rm{some text\ }\sigma=1\rm{\ some more text}$'
which is pretty bad. This might require some changes to how mathtext
is identified -- the presence of an even number of dollar signs is
probably sufficient, but in some corner cases might give the wrong
results, requiring a flag to overrride, etc. THat or we simply adopt
the TeX standard and require all literal $ to be quoted. THe latter
wil break some code but is probably better than anything else.
JDH

Eric Firing wrote:
> While you are at it, perhaps you can figure out how to stop 
> unicode_demo from generating an error:
>
> driving unicode_demo.py
> File "_tmp_unicode_demo.py", line 10
> SyntaxError: Non-ASCII character '\xe9' in file _tmp_unicode_demo.py 
> on line 10, but no encoding declared; see 
> http://www.python.org/peps/pep-0263.html for details
I have a fix for this I'll commit momentarily. The backend_driver 
inserts non-comment lines before the -*- coding line.
As for Unicode literals in Python source, there is a third option, other 
than u'\xd7' or ×ばつ'. Python will let you do u"\N{MULTIPLICATION SIGN}", 
which means you don't have to remember what \xd7 is. For single 
characters like this, I don't see much advantage (you can just name the 
variable something obvious), but for longer strings with embedded 
unicode characters (like docstrings), this might be something to consider.
Cheers,
Mike

I'm working on some improvements to the mathtext engine on a branch. 
Feel free to join in if curious, but I expect to break lots of things as 
I go.
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/
I've collected a bunch of math expressions from the source tree for use 
in regression testing. If you have any math strings of your own that 
you want to make sure I don't break, please send them to me (probably 
should be off-list to conserve noise).
Here's the preliminary TODO list I'm working with in no particular order 
(compiled from the TODO list in mathtext.py and the list of improvements 
in mathtext2.py):
1. Deal with nested sub/superscripts, such as $x_i_j,ドル equivalent to 
$x_{i_j}$
2. Make the font change tags (\cal, \tt, \rm etc.) behave more like TeX, 
e.g. use ${\rm sin}$ instead of $\rm{sin}$
3. Support roman function names, e.g. $\sin$ as a shortcut for ${\rm sin}$
4. Implement \frac
5. Other layout commands, like large \sqrt (I suspect there's a very 
large list of these things and they will have to be prioritized.)
6. Support kerning (probably best put off until we have good fonts with 
kerning information to use, e.g. STIX fonts)
...
(1 and 2 are already implemented in the branch.)
I don't want to start a long thread about all the desired features for 
mathtext -- I'm sure there are lots of them. There will need to be some 
way to prioritize, which I leave up to those on this list who have been 
around long enough to have a sense of what features are more pressing 
than others.
In general, is the goal with mathtext to become as TeX-compatible as 
possible (for some subset of standard TeX math syntax?) The reason I 
ask is, (1) above is not valid LaTeX and raises the error "Double 
subscript". Task (2) will break backward compatibility with existing 
matplotlib plots. In the long run, maintaining two codebases or two 
separate paths through the same codebase probably won't scale.
Cheers,
Mike

It looks like Edin made setuptools required in svn, which I just
reverted. Edin -- why? I'm a fan of setuptools, but I don't think we
should require a prerequisite that isn't necessary. Of course, if the
developers decide we want to require setuptools, I'm happy to support
the change, but it should probably have some kind of consensus.
Edin, if you want to use setuptools for your own installations, you can
do, from the command line
python -c "import setuptools; execfile('setup.py')" install
In fact, I have the attached script in my path, so I just type "ssetup
install" to use setuptools to install stuff. This also works with devel
mode. The script sets a few more things to handle assumptions that
setup.py files sometimes make.
-Andrew
Michael Droettboom wrote:
> As a stopgap measure until someone with more knowledge of these changes 
> replies, the following worked for me. In setup.py, uncomment the old 
> distutils import, and comment the new setuptools import:
> 
> #from distutils.core import Extension, setup
> from setuptools import setup
> 
> to
> 
> from distutils.core import Extension, setup
> #from setuptools import setup
> 
> Obviously not the "real" fix, but I was able to install and use pylab.
> 
> Cheers,
> Mike
> 
> Darren Dale wrote:
>> This morning I am having trouble installing from the svn repository. My home 
>> machine does not have setuptools installed, and the standard python setup.py 
>> install fails because it wants to import setuptools.
>>
>> If I install setuptools, I am able to install, but not run pylab:
>>
>> In [1]: from pylab import *
>> ---------------------------------------------------------------------------
>> <type 'exceptions.Exception'> Traceback (most recent call last)
>>
>> /home/darren/<ipython console> in <module>()
>>
>> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py 
>> in <module>()
>> ----> 1 from matplotlib.pylab import *
>> 2 import matplotlib.pylab
>> 3 __doc__ = matplotlib.pylab.__doc__
>>
>> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/pylab.py 
>> in <module>()
>> 198 """
>> 199 import sys, warnings
>> --> 200 import cm
>> 201 import _pylab_helpers
>> 202 import mlab #so I can override hist, psd, etc...
>>
>> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/cm.py 
>> in <module>()
>> 4
>> 5 import matplotlib as mpl
>> ----> 6 import matplotlib.colors as colors
>> 7 import matplotlib.numerix.npyma as ma
>> 8 import matplotlib.cbook as cbook
>>
>> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/matplotlib/colors.py 
>> in <module>()
>> 36 import re
>> 37 import warnings
>> ---> 38 import numpy as npy
>> 39 import matplotlib.numerix.npyma as ma
>> 40 import matplotlib.cbook as cbook
>>
>> /usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/__init__.py 
>> in <module>()
>> 44 import fft
>> 45 import random
>> ---> 46 import ctypeslib
>> 47
>> 48 # Make these accessible from numpy name-space
>>
>> /usr/lib/python2.5/site-packages/numpy-1.0.4.dev3884-py2.5-linux-i686.egg/numpy/ctypeslib.py 
>> in <module>()
>> 7
>> 8 try:
>> ----> 9 import ctypes
>> 10 except ImportError:
>> 11 ctypes = None
>>
>> /usr/lib/python2.5/site-packages/ctypes/__init__.py in <module>()
>> 26
>> 27 if __version__ != _ctypes_version:
>> ---> 28 raise Exception, ("Version number mismatch", __version__, 
>> _ctypes_version)
>> 29
>> 30 if _os.name in ("nt", "ce"):
>>
>> <type 'exceptions.Exception'>: ('Version number mismatch', '1.0.0', '1.0.2')
>>
>> Darren
>>
>> -------------------------------------------------------------------------
>> 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
>> 
> 
> 
> -------------------------------------------------------------------------
> 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

Darren Dale wrote:
[...]
> What about rendering unicode, but keeping the mpl sources ascii only?
This sounds like the thing to do for now.
While you are at it, perhaps you can figure out how to stop unicode_demo 
from generating an error:
 driving unicode_demo.py
 File "_tmp_unicode_demo.py", line 10
SyntaxError: Non-ASCII character '\xe9' in file _tmp_unicode_demo.py on 
line 10, but no encoding declared; see 
http://www.python.org/peps/pep-0263.html for details
> 
>> Undoubtedly unicode 
>> makes sense for the world in the long run, but for me it is an
>> unadulterated pain.
> 
> In that case, I imagine you are not eagerly anticipating the arrival of Py3K.
I am fairly open to attempts to make major improvements, or just clean 
things up. The unicode aspect of Py3K may make good sense in the long 
run, but I expect it will cause me some pain, and I am concerned that 
the use of unicode in source code will fragment the world's body of 
source code and may be conterproductive. The dominance of English is 
not entirely a bad thing, and its loss as a lingua franca may do more 
harm than good.
Eric

John Hunter wrote:
> On 7/16/07, Eric Firing <ef...@ha...> wrote:
> 
>> I use a good old-fashioned editor called zed, written by an Italian
>> named Sandro Serrafini who seems to have left no trace for several
>> years. I have modified it slightly, and I do minimal maintenance to
>> keep it compiling with new OS releases. Yes, I am familiar with emacs
>> and vi and nano and gedit and jed; I periodically survey the field of
>> editors. And yes, emacs will brew your morning coffee, but no, it won't
>> behave in the sane ways that I like an editor to behave.
>>
>> So the suggestion to start using unicode in source code is a nightmare
>> for me. Ascii is good: simple, universal, easy to work with, easy to
>> understand. One byte, one character. Unambiguous. Undoubtedly unicode
>> makes sense for the world in the long run, but for me it is an
>> unadulterated pain.
> 
> I am a huge emacs user, am am familiar with coffee.el though have
> never used it, but I think putting unicode into the src is a bad idea.
> Wouldn't this cause potential problems for people working over dumb
> terminals?
(Or for dumb people (me) working over terminals? Probably all terminals 
by now are smarter than I am.)
I think that unicode does require a whole level of support--something of 
a paradigm shift, not quite as jarring as command-line to gui, but still 
quite a bit of support infrastructure.
My understanding is that Python 3000 will be all-unicode, so I will have 
to get used to it and get a different editor or be left behind. But I 
am not looking forward to it, and don't want to do it any sooner than I 
have to.
Eric
> 
> JDH

On Monday 16 July 2007 01:25:18 pm Eric Firing wrote:
> Michael Droettboom wrote:
> > Darren Dale wrote:
> >> If not, should we use
> >> u'\xd7' or '=C3=97' in the actual sources (the latter requiring the fi=
le's
> >> encoding to be declared at the beginning of the file, like: # -*-
> >> coding: utf-8 -*-)?
> >
> > In an ideal world, I would prefer the latter, but we would want to
> > verify that all the matplotlib developers are using an editor that
> > respects those tags, or we could run into surprises if the files are
> > accidentally re-encoded.
> >
> > Cheers,
> > Mike
>
> I use a good old-fashioned editor called zed, written by an Italian
> named Sandro Serrafini who seems to have left no trace for several
> years. I have modified it slightly, and I do minimal maintenance to
> keep it compiling with new OS releases. Yes, I am familiar with emacs
> and vi and nano and gedit and jed; I periodically survey the field of
> editors. And yes, emacs will brew your morning coffee, but no, it won't
> behave in the sane ways that I like an editor to behave.
>
> So the suggestion to start using unicode in source code is a nightmare
> for me. Ascii is good: simple, universal, easy to work with, easy to
> understand. One byte, one character. Unambiguous.=20
What about rendering unicode, but keeping the mpl sources ascii only?
> Undoubtedly unicode=20
> makes sense for the world in the long run, but for me it is an
> unadulterated pain.
In that case, I imagine you are not eagerly anticipating the arrival of Py3=
K.

On 7/16/07, Eric Firing <ef...@ha...> wrote:
> I use a good old-fashioned editor called zed, written by an Italian
> named Sandro Serrafini who seems to have left no trace for several
> years. I have modified it slightly, and I do minimal maintenance to
> keep it compiling with new OS releases. Yes, I am familiar with emacs
> and vi and nano and gedit and jed; I periodically survey the field of
> editors. And yes, emacs will brew your morning coffee, but no, it won't
> behave in the sane ways that I like an editor to behave.
>
> So the suggestion to start using unicode in source code is a nightmare
> for me. Ascii is good: simple, universal, easy to work with, easy to
> understand. One byte, one character. Unambiguous. Undoubtedly unicode
> makes sense for the world in the long run, but for me it is an
> unadulterated pain.
I am a huge emacs user, am am familiar with coffee.el though have
never used it, but I think putting unicode into the src is a bad idea.
 Wouldn't this cause potential problems for people working over dumb
terminals?
JDH

Michael Droettboom wrote:
> Darren Dale wrote:
>> If not, should we use 
>> u'\xd7' or ×ばつ' in the actual sources (the latter requiring the file's 
>> encoding to be declared at the beginning of the file, like: # -*- coding: 
>> utf-8 -*-)?
> In an ideal world, I would prefer the latter, but we would want to 
> verify that all the matplotlib developers are using an editor that 
> respects those tags, or we could run into surprises if the files are 
> accidentally re-encoded.
> 
> Cheers,
> Mike
I use a good old-fashioned editor called zed, written by an Italian 
named Sandro Serrafini who seems to have left no trace for several 
years. I have modified it slightly, and I do minimal maintenance to 
keep it compiling with new OS releases. Yes, I am familiar with emacs 
and vi and nano and gedit and jed; I periodically survey the field of 
editors. And yes, emacs will brew your morning coffee, but no, it won't 
behave in the sane ways that I like an editor to behave.
So the suggestion to start using unicode in source code is a nightmare 
for me. Ascii is good: simple, universal, easy to work with, easy to 
understand. One byte, one character. Unambiguous. Undoubtedly unicode 
makes sense for the world in the long run, but for me it is an 
unadulterated pain.
Eric

Darren Dale wrote:
> If not, should we use 
> u'\xd7' or ×ばつ' in the actual sources (the latter requiring the file's 
> encoding to be declared at the beginning of the file, like: # -*- coding: 
> utf-8 -*-)?
In an ideal world, I would prefer the latter, but we would want to 
verify that all the matplotlib developers are using an editor that 
respects those tags, or we could run into surprises if the files are 
accidentally re-encoded.
Cheers,
Mike

I am cleaning up some of the code in ticker.ScalarFormatter, specifically s=
ome=20
of the text formatting for dealing with scientific notation.=20
We provide an option to format labels in sci. notation without using mathte=
xt=20
or usetex, in which case I would like to use the unicode multiplication sig=
n,=20
=C3=97 instead of x. Is there any reason not to do so? If not, should we us=
e=20
u'\xd7' or '=C3=97' in the actual sources (the latter requiring the file's=
=20
encoding to be declared at the beginning of the file, like: # -*- coding:=20
utf-8 -*-)? If we can use unicode, it might be nice to use real minus signs=
=20
as well, =E2=88=92123 rather than -123.
Darren

On 7/15/07, Paul Kienzle <pki...@ni...> wrote:
> Hi,
>
> I don't see an obvious way to remove a line from an axes object.
>
> Shall I add remove_child(h) which searches through all the lists
> of containers and removes the one that I don't want?
That's one way to do it, but you might consider something along the
lines -- every time someone adds an Artist anywhere in the figure,
they add an entry into a Figure remove dictionary that maps the artist
to a function to remove it
class Figure:
 def register_remove(self, artist, func):
 'register a function to remove an artist'
 self.removemap[artist] = func
 self.lastArtist = artist # this can be used to handle Gael's request
 def remove_artist(self, artist):
 'remove the artist'
 func = self.removemap.get(artist, None)
 if func is None: return
 func() # poof, it's gone
 del self.removemap(artist)
 def remove_last(self):
 'remove the most recently registered artist'
 self.remove_artist(self.lastArtist)
 self.lastArtist = None
class Axes:
 def add_line(self, line):
 self.figure.register_remove(line, lambda x: self.lines.remove(line))
 self.lines.append(line)
Then the user won't need to know whether the artist is stored by the
Axes, Axis, XTick, etc... This is likely more efficient and easier to
implement than recursively searching....
Users can then:
line, = ax.plot(something)
fig.remove_artist(line)
or
ax.fill(something)
fig.remove_last()
and a pylab interface will be trival
def remove_last():
 gcf().remove_last()
JDH