[matplotlib-devel] setup scripts
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 *
---
Traceback (most recent call last)
/home/darren/ in ()
/usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py
in ()
> 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 ()
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 ()
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 ()
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 ()
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 ()
7
8 try:
> 9 import ctypes
10 except ImportError:
11 ctypes = None
/usr/lib/python2.5/site-packages/ctypes/__init__.py in ()
26
27 if __version__ != _ctypes_version:
---> 28 raise Exception, ("Version number mismatch", __version__,
_ctypes_version)
29
30 if _os.name in ("nt", "ce"):
: ('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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] setup scripts
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 *
> ---
> Traceback (most recent call last)
>
> /home/darren/ in ()
>
> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py
>
> in ()
> > 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 ()
> 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 ()
> 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 ()
> 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 ()
> 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 ()
> 7
> 8 try:
> > 9 import ctypes
> 10 except ImportError:
> 11 ctypes = None
>
> /usr/lib/python2.5/site-packages/ctypes/__init__.py in ()
> 26
> 27 if __version__ != _ctypes_version:
> ---> 28 raise Exception, ("Version number mismatch", __version__,
> _ctypes_version)
> 29
> 30 if _os.name in ("nt", "ce"):
>
> : ('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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] remove artist from axes?
On 7/15/07, Paul Kienzle <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] unicode question
I am cleaning up some of the code in ticker.ScalarFormatter, specifically some of the text formatting for dealing with scientific notation. We provide an option to format labels in sci. notation without using mathtext or usetex, in which case I would like to use the unicode multiplication sign, × instead of x. Is there any reason not to do so? 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 -*-)? If we can use unicode, it might be nice to use real minus signs as well, −123 rather than -123. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
On 7/16/07, Eric Firing <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
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 '×' 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. What about rendering unicode, but keeping the mpl sources ascii only? > 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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
John Hunter wrote: > On 7/16/07, Eric Firing <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] setup scripts
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 *
>> ---
>> Traceback (most recent call last)
>>
>> /home/darren/ in ()
>>
>> /usr/lib/python2.5/site-packages/matplotlib-0.90.1_r3536-py2.5-linux-i686.egg/pylab.py
>>
>> in ()
>> > 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 ()
>> 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 ()
>> 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 ()
>> 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 ()
>> 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 ()
>> 7
>> 8 try:
>> > 9 import ctypes
>> 10 except ImportError:
>> 11 ctypes = None
>>
>> /usr/lib/python2.5/site-packages/ctypes/__init__.py in ()
>> 26
>> 27 if __version__ != _ctypes_version:
>> ---> 28 raise Exception, ("Version number mismatch", __version__,
>> _ctypes_version)
>> 29
>> 30 if _os.name in ("nt", "ce"):
>>
>> : ('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
>> [email protected]
>> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
#!/bin/sh
# ssetup - "setuptools setup"
python -c "import setuptools,
sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
$*
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version o
[matplotlib-devel] Mathtext improvements
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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements
John Hunter wrote:
> On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] setup scripts
On 7/16/07, Andrew Straw <[EMAIL PROTECTED]> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> 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.
There's also a TeX -> "unicode integer representation" dict in
_mathtext_data.py. It's called tex2uni.
You use it like this (notice no backslashes):
>>> from matplotlib._mathtext_data import tex2uni
>>> unichr(tex2uni['int'])
u'\u222b'
>>> unichr(tex2uni['sum'])
u'\u2211'
Cheers,
Edin
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> 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
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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements
On Monday 16 July 2007 02:32:30 pm John Hunter wrote:
> On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> 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.
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode question
On 7/16/07, Edin Salkovic <[EMAIL PROTECTED]> 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 . You might simply define some constants at the ticker module level for efficient reuse, eg usumchar = unichr(tex2uni['sum']) etc... - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] numpification and imports
On Friday 13 July 2007 06:29:59 pm Eric Firing wrote:
> Eric Firing wrote:
> > John Hunter wrote:
> >> On 7/13/07, Ted Drain <[EMAIL PROTECTED]> 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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements
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 [EMAIL PROTECTED] - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] numpification and imports
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] numpification and imports
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
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On 7/16/07, Eric Firing <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
John Hunter wrote: > On 7/16/07, Eric Firing <[EMAIL PROTECTED]> 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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
Robert Kern wrote: [...] > 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. When do you expect to make a release? Eric - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] remove artist from axes?
On Mon, Jul 16, 2007 at 08:38:17AM -0500, John Hunter wrote: > On 7/15/07, Paul Kienzle <[EMAIL PROTECTED]> 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) I'm not to keen on yet another registry, especially since it will have to be maintained when, e.g., cla() is called. How about storing the remove function with the artist itself? Then it would just be h.remove() rather than fig.remove_artist(h). BTW, I can't think of a use case for 'remove last' from an applications standpoint. Maybe it would be useful to someone entering plot commands from the console, but even then it is a poor substitute for 'undo'. > 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 On the topic of efficiency, every tick line (1,2) grid line (1,2) and every tick label (1,2) has an artist associated with it. Is there any reason not to represent this as one or two line collections and a text collection? Our application has multiple panels in a wxAUI interface, and graph rendering is slow even on tiny data sets. - Paul - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote: > On 7/16/07, Eric Firing <[EMAIL PROTECTED]> 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 :-) I am very happy to hear this. I have been using traits for lab work, and it has been an absolute pleasure (ask Fernando, he has heard me express my satisfaction over and over). I have converted a friend, here, in France to traits for some software his company is developing, and every body has been amazed at the results. Traits come with added benefits than validation: * Traits handlers, they allow nice event driven programming in a light way. Think of it this way: you have a mappable artist, its colormap is a traits, you have a handler triggered when you change this colormap that automatically redraw the axes. If you use this pattern heavily, the drawing package becomes much nicer to use we integrating in an interactive program. * TraitsUI. Once everything is traited, and each artist has its properties discribed by traits, you edit these properties graphically, traits can create automatically dialogs for them (see http://code.enthought.com/traits/ for an example with screenshots). Now this is Wx only, so far, so it would be very limited. However graphical edition of figures and artists is a feature my colleagues ask often, and having traits would make it one step closer. My 2 cents, Gaël - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
