matplotlib-devel Mailing List for matplotlib (Page 3)

On Wed, Dec 12, 2007 at 06:39:02PM -0700, Fernando Perez wrote:
> On second thought though: __str__ is the one meant for 'human
> consumption', while __repr__ is deliberately meant to be much more
> machine-like. Basically the idea is that, whenever possible, one can
> do
> x == eval(repr(x))
> That is true for many of the builtin data types of the language.
I totally agree. However if a user types:
pylab.rcParams
in IPython, or the Python interpreter, she gets the repr, AFAIK. I would
like this display to be readable.
Gaël

On Thu, Dec 13, 2007 at 09:30:44AM +0100, Gael Varoquaux wrote:
> On Wed, Dec 12, 2007 at 06:39:02PM -0700, Fernando Perez wrote:
> > On second thought though: __str__ is the one meant for 'human
> > consumption', while __repr__ is deliberately meant to be much more
> > machine-like. Basically the idea is that, whenever possible, one can
> > do
> > x == eval(repr(x))
> > That is true for many of the builtin data types of the language.
> I totally agree. However if a user types:
> pylab.rcParams
> in IPython, or the Python interpreter, she gets the repr, AFAIK. I would
> like this display to be readable.
OK, this is what I currently have:
"""
In [1]: import simpleconf
In [2]: simpleconf.SimpleConfig()
Out[2]: 
datafile = 'data.txt' # a value of type 'str' or a value of type 'unicode'
solver = 'Direct' # 'Direct' or 'Iterative'
Protocol.max_users = 1 # a value of type 'int'
Protocol.ptype = 'http' # 'http' or 'ftp' or 'ssh'
"""
I would like to make it as easy as possible for users to understand how
to modify configuration options. Comments are welcomed.
Gaël

On 2007年12月13日 09:07:42 +0100
 "Nils Wagner" <nw...@ia...> wrote:
> Hi all,
> 
> It should be float32 instead of Float32.
> 
> python logo.py
> Traceback (most recent call last):
> File "logo.py", line 7, in ?
> x = 1000*0.1*fromstring(
> NameError: name 'Float32' is not defined
> 
> Nils
> 
 
Actually there are some more NameErrors in the examples
grep -w 'Float*' *.py
mri_demo.py:im = fromstring(file(dfile, 'rb').read(), 
UInt16).astype(Float)
rc_traits.py: linewidth = traits.Float(0.5)
rc_traits.py: markeredgewidth = traits.Float(0.5)
rc_traits.py: markersize = traits.Float(6)
rc_traits.py: linewidth = traits.Float(1.0)
rc_traits.py: linewidth = traits.Float(0.5)
python mri_demo.py
Traceback (most recent call last):
 File "mri_demo.py", line 6, in ?
 im = fromstring(file(dfile, 'rb').read(), 
UInt16).astype(Float)
NameError: name 'UInt16' is not defined
Nils

Hi all,
It should be float32 instead of Float32.
python logo.py
Traceback (most recent call last):
 File "logo.py", line 7, in ?
 x = 1000*0.1*fromstring(
NameError: name 'Float32' is not defined
Nils

On Dec 12, 2007 5:58 PM, Gael Varoquaux <gae...@no...> wrote:
> Hi,
>
> I definetely don't like the fact that .__repr__() and repr() are used all
> over TConfig for eg storing to file.
>
> First of all I would like to modify __repr__ for a TConfig class to give
> a more synthetic view.
>
> I propose to change the current ".__repr__()" method to ".tostring()" and
> to implement a more readable ".__repr__()".
>
> Are the different people interested in these issues OK with that? If yes,
I'm OK with it.
> where is the authoritative repo for TConfig? Which SVN should I start
> hacking?
It's probably easier for now to use ipython, since both you and Darren
both have SVN write access to it. Unless Darren has a different
opinion...
Cheers,
f

On Dec 12, 2007 7:16 AM, Paul Kienzle <pki...@ni...> wrote:
> I'm curious about the term 'threading backend'.
>
> Recently I posted a question about how to handle slow plots, suggesting
> that the backend canvas have an isabort() method so that the renderer
> can stop what it is doing and post the current bitmap as it stands.
> This is to support interactive operations such as panning and resizing
> on large data collections.
>
> Do you mean something similar when you say 'threading backend', and is
> it already supported in IPython?
No, it just means that ipython can run in conjunction with the major
GUI toolkits in a non-blocking manner. In a plain python shell, if
you open a plot window (for any backend other than Tk), you can't go
back to the prompt and keep typing until you close the plot. IPython
allows that to happen, with Wx, GTK, Qt and Qt4.
Cheers,
f

On Dec 12, 2007 6:34 PM, Darren Dale <dar...@co...> wrote:
>
> On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote:
> > Hi,
> >
> > I definetely don't like the fact that .__repr__() and repr() are used all
> > over TConfig for eg storing to file.
> >
> > First of all I would like to modify __repr__ for a TConfig class to give
> > a more synthetic view.
> >
> > I propose to change the current ".__repr__()" method to ".tostring()" and
> > to implement a more readable ".__repr__()".
> >
> > Are the different people interested in these issues OK with that? If yes,
> > where is the authoritative repo for TConfig? Which SVN should I start
> > hacking?
>
> I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it
> doesnt matter in practice because I keep the two in sync.
>
> I do want to be able to save the verbose information to a file, since we want
> to be able to generate a commented file that people can use to learn how to
> make modifications. If that doesnt change, I don't have an objection to
> making __repr__ terse.
On second thought though: __str__ is the one meant for 'human
consumption', while __repr__ is deliberately meant to be much more
machine-like. Basically the idea is that, whenever possible, one can
do
x == eval(repr(x))
That is true for many of the builtin data types of the language.
Quoting http://docs.python.org/ref/customization.html#l2h-179 :
__repr__( 	self)
 Called by the repr() built-in function and by string conversions
(reverse quotes) to compute the ``official'' string representation of
an object. If at all possible, this should look like a valid Python
expression that could be used to recreate an object with the same
value (given an appropriate environment). If this is not possible, a
string of the form "<...some useful description...>" should be
returned. The return value must be a string object. If a class defines
__repr__() but not __str__(), then __repr__() is also used when an
``informal'' string representation of instances of that class is
required.
 This is typically used for debugging, so it is important that the
representation is information-rich and unambiguous.
So Gael, would you be OK with a terser str() and leaving repr to honor
this python convention?
Cheers,
f

On Wednesday 12 December 2007 7:58:10 pm Gael Varoquaux wrote:
> Hi,
>
> I definetely don't like the fact that .__repr__() and repr() are used all
> over TConfig for eg storing to file.
>
> First of all I would like to modify __repr__ for a TConfig class to give
> a more synthetic view.
>
> I propose to change the current ".__repr__()" method to ".tostring()" and
> to implement a more readable ".__repr__()".
>
> Are the different people interested in these issues OK with that? If yes,
> where is the authoritative repo for TConfig? Which SVN should I start
> hacking?
I consider the authoritative TConfig to be the one in Ipython1.sandbox, but it 
doesnt matter in practice because I keep the two in sync. 
I do want to be able to save the verbose information to a file, since we want 
to be able to generate a commented file that people can use to learn how to 
make modifications. If that doesnt change, I don't have an objection to 
making __repr__ terse.
Darren

Hi,
I definetely don't like the fact that .__repr__() and repr() are used all
over TConfig for eg storing to file.
First of all I would like to modify __repr__ for a TConfig class to give
a more synthetic view.
I propose to change the current ".__repr__()" method to ".tostring()" and
to implement a more readable ".__repr__()".
Are the different people interested in these issues OK with that? If yes,
where is the authoritative repo for TConfig? Which SVN should I start
hacking?
Cheers,
Gaël

If we're going to use setuptools (actually already required for Python=20
2.3), I think we need to do it completely and not optionally --=20
otherwise users will start to depend on its features, which simply won't =
be there in some cases. In particular, I suspect they will make use of=20
the dependency resolution mechanisms. As I suggested on the ipython-dev=20
list this will do what you want without requiring a change to setup.py:
python -c "import setuptools; execfile('setup.py')" develop
Gael Varoquaux wrote:
> Hi,
>
> I just sent a similar e-mail to the ipython-def mailing list:
> I am not a big proponent of setuptools, but I must admit they have real=
ly
> nice feature for developpers: "python setup.py develop", which does the=
> Python equivalent of a symlink during the install so that it uses the
> source code from the check out to run.
>
> I would like to add these lines to the setup.py:
>
> """
> try:
> from setuptools import setup, find_packages
> except ImportError:
> pass
> """
>
> I cannot see waht harm this can do, and I can see the benefit: I instal=
l
> an svn checkout of MPL with:
>
> """
> sudo python setup.py develop --prefix /usr/local
> """
>
> and then maintain this check out by doing "svn up", and this even in
> windows.
>
> What do you think?
>
> Ga=EBl
>
> -----------------------------------------------------------------------=
--
> SF.Net email is sponsored by:=20
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20

On Dec 12, 2007 1:29 PM, Mark Bakker <ma...@gm...> wrote:
> It seems that in the latest version (0.9.1) the location of the images, such
> as home.ppm, has moved to a new directory.
> It used to be in ...\mpl-data and now it is in ...\mpl-data\images
>
> This totally breaks my code, as I use my own toolbar that uses these images,
> with a hardcoded location of the ppm files. I know, I should from now on
> distribute these ppm files with the distribution of my own program, but
> there may be others that have this problem.
>
> Not sure what the best solution is. WIll it remain in this new images
> directory from now on?
Can't say for sure, but we have no plans to move it. You may want to
follow the API_CHANGES at http://matplotlib.sf.net/API_CHANGES, which
we update whenever we do something that breaks code. This move to the
images subdirectory in the install directory was noted with:
 Moved data files into lib/matplotlib so that setuptools' develop
 mode works. Re-organized the mpl-data layout so that this source
 structure is maintained in the installation. (I.e. the 'fonts' and
 'images' sub-directories are maintained in site-packages.).
 Suggest removing site-packages/matplotlib/mpl-data and
 ~/.matplotlib/ttffont.cache before installing
Admittedly a bit cryptic.
JDH
>
> Thanks,
>
> Mark
>
> ps. Cross-posted on the users and development list
> ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
> needed to point out this backwards incompatibility, which may just be ugly
> coding on my part
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hello -
It seems that in the latest version (0.9.1) the location of the images, such
as home.ppm, has moved to a new directory.
It used to be in ...\mpl-data and now it is in ...\mpl-data\images
This totally breaks my code, as I use my own toolbar that uses these images,
with a hardcoded location of the ppm files. I know, I should from now on
distribute these ppm files with the distribution of my own program, but
there may be others that have this problem.
Not sure what the best solution is. WIll it remain in this new images
directory from now on?
Thanks,
Mark
ps. Cross-posted on the users and development list
ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
needed to point out this backwards incompatibility, which may just be ugly
coding on my part

On Wed, Dec 12, 2007 at 01:40:38PM -0500, Charlie Moad wrote:
> We added "setupegg.py" a long time ago which does exactly this. The
> line below would then be:
> python setupegg.py develop
Sorry. I am being really brain dead today.
Thanks,
Gaël

We added "setupegg.py" a long time ago which does exactly this. The
line below would then be:
python setupegg.py develop
On Dec 12, 2007 12:35 PM, Gael Varoquaux <gae...@no...> wr=
ote:
> On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> > If we're going to use setuptools (actually already required for Python
> > 2.3), I think we need to do it completely and not optionally --
> > otherwise users will start to depend on its features, which simply won'=
t
> > be there in some cases. In particular, I suspect they will make use of
> > the dependency resolution mechanisms. As I suggested on the ipython-dev
> > list this will do what you want without requiring a change to setup.py:
>
> > python -c "import setuptools; execfile('setup.py')" develop
>
> OK, I'll settle for this.
>
> Ga=EBl
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl=
ace
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> If we're going to use setuptools (actually already required for Python 
> 2.3), I think we need to do it completely and not optionally -- 
> otherwise users will start to depend on its features, which simply won't 
> be there in some cases. In particular, I suspect they will make use of 
> the dependency resolution mechanisms. As I suggested on the ipython-dev 
> list this will do what you want without requiring a change to setup.py:
> python -c "import setuptools; execfile('setup.py')" develop
OK, I'll settle for this.
Gaël

Hi,
I just sent a similar e-mail to the ipython-def mailing list:
I am not a big proponent of setuptools, but I must admit they have really
nice feature for developpers: "python setup.py develop", which does the
Python equivalent of a symlink during the install so that it uses the
source code from the check out to run.
I would like to add these lines to the setup.py:
"""
try:
 from setuptools import setup, find_packages
except ImportError:
 pass
"""
I cannot see waht harm this can do, and I can see the benefit: I install
an svn checkout of MPL with:
"""
sudo python setup.py develop --prefix /usr/local
"""
and then maintain this check out by doing "svn up", and this even in
windows.
What do you think?
Gaël

I'm curious about the term 'threading backend'.
Recently I posted a question about how to handle slow plots, suggesting
that the backend canvas have an isabort() method so that the renderer
can stop what it is doing and post the current bitmap as it stands.
This is to support interactive operations such as panning and resizing
on large data collections.
Do you mean something similar when you say 'threading backend', and is
it already supported in IPython?
 - Paul
On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> Hi all,
> 
> This was posted to the ipython-dev list, but since it's specifically
> for MPL, I figured the cross-list spam would be forgiven.
> 
> In IPython SVN, I just added the ability to manually control the pylab
> threading backend choice directly from the command line. So for
> example if by default you have:
> 
> tlon[~]> ipython -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'TkAgg'
> 
> You can now do this as well:
> 
> tlon[~]> ipython -wthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
> 
> In [2]:
> Closing threads... Done.
> tlon[~]> ipython -gthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'GTKAgg'
> 
> The feature is fairly simplistic: the -Xthread flags map automatically
> to the XAgg backends in MPL, with no more fine-grained choice than
> that. We can later look into allowing explicit backend selection if
> you really scream for it, but I'd rather keep this simple. This means
> that if you don't have the *Agg builds of the GUI backends, you'll
> still need to do the backend selection by hand as before (i.e. by
> modifying your mpl config file).
> 
> This has often been requested and I'd needed it myself on multiple
> occasions, so it's finally in.
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

You could add some semi-transparent text across the figure with 
something like:
gcf().text(0.1, 0.1, "Watermark", rotation=45, 
fontproperties=FontProperties(size=64), alpha=0.2)
Unfortunately, alpha-transparency on text is not supported in the Agg 
and Svg backends (more due to an oversight than it being terribly 
difficult to implement -- I can try to get this in for the 0.91.2 
release). But it does work on Pdf and Cairo. (Supporting it in Ps will 
be quite difficult).
There may also be external tools to do this *after* generating the plot 
from matplotlib, e.g.:
http://www.selonen.org/arto/netbsd/watermarks.html
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
> 
> Is it possible to add a water mark to a plot ?
> 
> Nils
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> You can now do this as well:
> tlon[~]> ipython -wthread -pylab --nobanner
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
Hurray, mayavi and pylab can now easily live together. Thanks heaps
Fernando.
Gaël

Hi all,
This was posted to the ipython-dev list, but since it's specifically
for MPL, I figured the cross-list spam would be forgiven.
In IPython SVN, I just added the ability to manually control the pylab
threading backend choice directly from the command line. So for
example if by default you have:
tlon[~]> ipython -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'TkAgg'
You can now do this as well:
tlon[~]> ipython -wthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'WXAgg'
In [2]:
Closing threads... Done.
tlon[~]> ipython -gthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'GTKAgg'
The feature is fairly simplistic: the -Xthread flags map automatically
to the XAgg backends in MPL, with no more fine-grained choice than
that. We can later look into allowing explicit backend selection if
you really scream for it, but I'd rather keep this simple. This means
that if you don't have the *Agg builds of the GUI backends, you'll
still need to do the backend selection by hand as before (i.e. by
modifying your mpl config file).
This has often been requested and I'd needed it myself on multiple
occasions, so it's finally in.
Cheers,
f

Hi all,
Is it possible to add a water mark to a plot ?
Nils

On Dec 11, 2007 6:51 PM, Paul Kienzle <pki...@ni...> wrote:
> I removed the mpl_connect from the scroll event to pick. I don't know
> why it was there.
>
> I tested the patch on OS X WxAgg examples/image_slice_viewer.
>
> Let me know if it is okay to post to svn, or if we are still in feature
> freeze.
As long as you are reasonably confident that this won't break existing
code, go ahead and commit it. In the next day or two, if nothing else
serious arises, I'd like to cut 0.91.2 if Charlie has time.
JDH

Hi,
I have a patch which implements the scroll wheel on wx using the
wx mouse wheel event.
Rather than a simple up/down mouse event wx uses:
 delta: intervals per click
 rotation: number of clicks
 rate: number of lines per click
I convert this to: 
 step = rotation*delta/rate
I've added the step attribute to the mpl MouseEvent in addition to the
usual up/down button (up if step >= 0, down otherwise). 
I removed the mpl_connect from the scroll event to pick. I don't know
why it was there.
I tested the patch on OS X WxAgg examples/image_slice_viewer.
Let me know if it is okay to post to svn, or if we are still in feature
freeze.
	- Paul

On Dec 11, 2007 5:42 PM, Gael Varoquaux <gae...@no...> wrote:
> On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote:
> > The tconfig objects already have a very dict-like representation for
> > dumping into a text file, the .ini format. Or do you mean something
> > that's even closer to a dict, curly braces and all?
>
> No, I don't care about the curly brace. However, I don't want the
> comments. I haven't decided yet, but I am sure that I want something that
> a bit more compact than, eg "print MPLConfig()".
I see, makes sense. Hack away, I trust your judgment :)
> > > The problem is that it would break your script, so I can't send you a
> > > patch. I'd like the codebase to stay similar, so maybe we can discuss
> > > this once I have some code.
>
> > Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
> > mayavi-tconfig :)
>
> Yes, lets try to keep this united. I'll probably also work on a nice
> TraitsUI view. If all three projects can use the same model, view and
> controler for the configuration file, that will make it easier to, one
> day, present a unified configuration editor for a scientific IDE (:->).
Indeed. Once we have the code in place, we'll worry about organizing
things for easy reuse.
Cheers,
f

On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote:
> The tconfig objects already have a very dict-like representation for
> dumping into a text file, the .ini format. Or do you mean something
> that's even closer to a dict, curly braces and all?
No, I don't care about the curly brace. However, I don't want the
comments. I haven't decided yet, but I am sure that I want something that
a bit more compact than, eg "print MPLConfig()".
> > The problem is that it would break your script, so I can't send you a
> > patch. I'd like the codebase to stay similar, so maybe we can discuss
> > this once I have some code.
> Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
> mayavi-tconfig :)
Yes, lets try to keep this united. I'll probably also work on a nice
TraitsUI view. If all three projects can use the same model, view and
controler for the configuration file, that will make it easier to, one
day, present a unified configuration editor for a scientific IDE (:->).
Gaël