matplotlib-devel Mailing List for matplotlib (Page 12)

John Hunter wrote:
> On 7/16/07, Eric Firing <ef...@ha...> wrote:
> 
>> Are any real, live projects outside of enthought making major use of
>> traits? Or would we be the first?
Yes. Most are in the somewhat formative stages, so you may not think they count
(which is fine).
> I am happy to be the first at this point -- enthought has done a lot
> to support traits. Traits has one of the most impressive pieces of
> technical documentation in the scientific python community. The
> enthought mailing list has become quite active of late, and they are
> clearly supporting their OS code. They actively promote their product
> and want a large user community -- we can provide synergy there. It
> has lived in our src tree for over a year and still "just compiles".
> In fact, I am amenable too, though not committed to, requiring
> traits as an *external* package rather than an included package, both
> to encourage users into the ETS suite and to encourage enthought to
> support us via their traits package. I'd be happy to hear from
> enthought here on their preferences. 
We've split up the main "enthought" package such that Traits can be installed
separately as "enthoguht.traits". I think we'd prefer depending on it externally
now that we've spent so much effort to make that feasible.
>> I am happy to see this in svn:
>>
>> Revision 12335, 13.4 kB (checked in by rkern, 4 weeks ago)
>> Array trait updated to use numpy idioms only.
> 
> Anything that gets Robert making commits to our tree is a massive win for us.
Flattery will get you nowhere.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On 7/16/07, Eric Firing <ef...@ha...> wrote:
> Are any real, live projects outside of enthought making major use of
> traits? Or would we be the first?
I am happy to be the first at this point -- enthought has done a lot
to support traits. Traits has one of the most impressive pieces of
technical documentation in the scientific python community. The
enthought mailing list has become quite active of late, and they are
clearly supporting their OS code. They actively promote their product
and want a large user community -- we can provide synergy there. It
has lived in our src tree for over a year and still "just compiles".
 In fact, I am amenable too, though not committed to, requiring
traits as an *external* package rather than an included package, both
to encourage users into the ETS suite and to encourage enthought to
support us via their traits package. I'd be happy to hear from
enthought here on their preferences. With the whole Numeric, numarray
and numpy thing behind us, I'm looking for a whole new set of
compilation issues to tackle :-)
> Actually, it could be completely split into two phases: first rcParams
> handling, second Artist properties, couldn't it? Starting with rc would
> be nice because it would provide a gentler introduction and some
> experience; but I think that using traits for Artist properties can also
> be done piecemeal, so it shouldn't be too disruptive.
True, but there aren't that many Artists, and they are closely tied to
the rc params. Once you get the rc done, it will be natural and easy
to do the artists. But yes, you can do them piecemeal: Line2D and
Text are natural first targets.
> > If you decide to go that route, let's sync up with the latest
> > enthought tree first, though.
>
> I am happy to see this in svn:
>
> Revision 12335, 13.4 kB (checked in by rkern, 4 weeks ago)
> Array trait updated to use numpy idioms only.
Anything that gets Robert making commits to our tree is a massive win for us.
JDH

John Hunter wrote:
[...]
> Isn't there a potential problem here? The original validate funcs
> support conversion from a string to a value, but you are proposing
> using them here in a context where users will generally be supplying a
> (possibly bogus) value, but in general not a string. So the existing
> funcs may not work wholesale, but might be easily adapted.
What about Fernando's ipython strategy: parse the rc file as python 
code, not as strings? I don't think the changeover would be very hard; 
most of the present matplotlibrc file is commented out anyway, so unless 
users are doing lots of customization it would not be difficult for them 
to generate a matplotlibrc file in python form.
> 
> As for key validation, I was only suggesting you raise a helpful error
> message if the user supplies a bogus key.
> 
> As for traits, I think we are psychologically committed to them, and
> if you are looking for a good summertime project, this might be a good
> candidate. It's not really a chainsaw question, because you could
That's why I brought it up--although every time I look at traits I pull 
back, worrying about the very large amount of machinery they involve. 
Are any real, live projects outside of enthought making major use of 
traits? Or would we be the first?
> easily support traits in the Artist layer and rc layer w/o ripping out
> the fundamental organization, and we could write setter and getter
> support as thin warppers around traits to avoid significant API
> breakage. There are deeper and more fundamental chainsaw like layers
> where traits would help us (eg transform updates on window resizes)
> but a clear cut first step would be to get the Artist properties
> traitified.
Actually, it could be completely split into two phases: first rcParams 
handling, second Artist properties, couldn't it? Starting with rc would 
be nice because it would provide a gentler introduction and some 
experience; but I think that using traits for Artist properties can also 
be done piecemeal, so it shouldn't be too disruptive.
> 
> If you decide to go that route, let's sync up with the latest
> enthought tree first, though.
I am happy to see this in svn:
 Revision 12335, 13.4 kB (checked in by rkern, 4 weeks ago)
Array trait updated to use numpy idioms only.
Eric

On 7/16/07, Darren Dale <dd...@co...> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should also try to do something about the rc file format, so we dont have to
> parse and convert strings before validating. Someone had suggested python
> literals, I think John or Fernando might have had some ideas about this at
> one point... I dont know the details.
Hey Darren,
Isn't there a potential problem here? The original validate funcs
support conversion from a string to a value, but you are proposing
using them here in a context where users will generally be supplying a
(possibly bogus) value, but in general not a string. So the existing
funcs may not work wholesale, but might be easily adapted.
As for key validation, I was only suggesting you raise a helpful error
message if the user supplies a bogus key.
As for traits, I think we are psychologically committed to them, and
if you are looking for a good summertime project, this might be a good
candidate. It's not really a chainsaw question, because you could
easily support traits in the Artist layer and rc layer w/o ripping out
the fundamental organization, and we could write setter and getter
support as thin warppers around traits to avoid significant API
breakage. There are deeper and more fundamental chainsaw like layers
where traits would help us (eg transform updates on window resizes)
but a clear cut first step would be to get the Artist properties
traitified.
If you decide to go that route, let's sync up with the latest
enthought tree first, though.
JDH
JDH

On 7/16/07, Darren Dale <dd...@co...> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should also try to do something about the rc file format, so we dont have to
> parse and convert strings before validating. Someone had suggested python
> literals, I think John or Fernando might have had some ideas about this at
> one point... I dont know the details.
In the new ipython work, we went for pure-python configuration files.
Given how ipython (and mpl) is only of use to python programmers, we
didn't see much the benefit of shielding users from the python syntax,
and certainly lots of downsides to it.
Obviously using a full programming language in a config file opens up
potential complexities and problems, but I think for ipython it was
the right choice.
Cheers,
f

On Monday 16 July 2007 7:22:37 pm you wrote:
> 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. 
That was my impression as well, it looks like it would fit well with the 
existing 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.)
John wrote rc_traits.py, before numpy was around, by the looks of it. Traits 
seem more appealing to me than properties, but I was looking for something 
that could be done outside of a chainsaw branch. If we decided on traits, we 
should also try to do something about the rc file format, so we dont have to 
parse and convert strings before validating. Someone had suggested python 
literals, I think John or Fernando might have had some ideas about this at 
one point... I dont know the details.
Darren

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