matplotlib-devel Mailing List for matplotlib

Hi folks,
David Warde-Farley kindly set up a page to coordinate BoF attendance
at the conference, in case anyone on this list is interested. Details
below.
Cheers,
f
---------- Forwarded message ----------
From: David Warde-Farley <dw...@cs...>
Date: Thu, Aug 13, 2009 at 2:20 PM
Subject: [IPython-user] SciPy2009 BoF Wiki Page
To: SciPy Users List <sci...@sc...>, Discussion of Numerical
Python <num...@sc...>, ipy...@sc...
I needed a short break from some heavy writing, so on Fernando's
suggestion I took to the task of aggregating together mailing list
traffic about the BoFs next week. So far, 4 have been proposed, and
I've written down under "attendees" the names of anyone who has
expressed interest (except in Perry's case, where I've only heard it
via proxy). The page is at
    http://scipy.org/SciPy2009/BoF
I've created sections below that are hyperlink targets for the topic
of the session, if someone more knowledgeable of that domain can fill
in those sections, please do.
Edit away, and see you next week! (And if someone can forward this to
the Matplotlib list, I'm not currently subscribed)
David
_______________________________________________
IPython-user mailing list
IPy...@sc...
http://mail.scipy.org/mailman/listinfo/ipython-user

Hi - it was something to do with that. When I now *add*:
./matplotlib-0.98.5.2n2-py2.5-macosx-10.3-fat.egg,
which was the version that EPD instaled, to easy-install.pth, I get
back version 0.98.5
On Thu, Aug 13, 2009 at 9:25 AM, Gael
Varoquaux<gae...@no...> wrote:
> On Thu, Aug 13, 2009 at 09:30:22AM -0600, Jeff Whitaker wrote:
>> Ariel Rokem wrote:
>> > Resending with CC to list:
>
>> > D'oh. I forgot to do that. OK - now I went back and ran:
>
>> > env ARCHFLAGS='-arch i386' python setup.py install
>
>> > That also went with no hitches
>
>> > Then, in Python:
>
>
>> >>>> import matplotlib
>> >>>> matplotlib.__version__
>
>> > '0.98.5.2'
>
>
>> Ariel: This tells me you really didn't install it, or you installed it
>> in a different version of python than you are trying to import it with.
>
>> > So - still no version update. I ran:
>
>> > 'easy_install matplotlib', which somehow seems to change the path
>> > setting to find the most recent version of things (maybe someone here
>> > can tell me how this happens?) now:
>
>
> I am not sure that Ariel didn't install things right. He might be a
> victim of setuptools' monkey patching of sys.path. Ariel, you should go
> around in the various easy_install.pth in the different folder on you
> Python path (that is the system ones as well as the ones in your
> $PYTHONPATH) and make sure that any reference to matplotlib is removed.
>
> Gaël
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Jason R. Coombs wrote:
> I'm about to upload a new patch that implements some of the ideas John and
> Darren have sent. Would you mind running the performance tests against that
> one also? This new change has the potential to increase performance drag.
I tested it; performance still is not a problem.
firing@manini:~/programs/py/mpl/tests$ python startuptime.py
average pylab startup time: 0.505041065216
efiring@manini:~/programs/py/mpl/tests$ python startuptime.py
average pylab startup time: 0.508669295311
where the first number is r7480, and the second is after your patch #4.
The test script is attached.
Eric

Jason R. Coombs wrote:
> I'm about to upload a new patch that implements some of the ideas John and
> Darren have sent. Would you mind running the performance tests against that
> one also? This new change has the potential to increase performance drag.
> 
> Jason
I'll test it, but it might be a few hours.
Eric

I'm about to upload a new patch that implements some of the ideas John and
Darren have sent. Would you mind running the performance tests against that
one also? This new change has the potential to increase performance drag.
Jason
> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...]
> Sent: Thursday, 13 August, 2009 15:37
> To: John Hunter
> Cc: Jason R. Coombs; Darren Dale; matplotlib development list
> Subject: Re: [matplotlib-devel] kwdoc processing with decorators
> 
> 
> I tested the startup time for r7480 before and after the patch, and the
> difference is quite small--of the order of a percent--so I have no
> objection to the patch on that account. Or, for that matter, on any
> other account. I would not object to applying it (or a modification,
> if
> there is still fine-tuning to be done) to the trunk. It seems to work
> fine. John, I assume you have tested doc building with the patch in
> place. I have not.
> 
> Eric

John Hunter wrote:
> On Thu, Aug 13, 2009 at 1:08 PM, Eric Firing<ef...@ha...> wrote:
> 
>> Ideally, all the docstring manipulations would be done once at the time of
>> installation or of compilation to .pyc, not at every mpl startup. I think
>> that doing it at compilation time is impossible, given python's fundamental
>> design, so that leaves the installation time alternative. I don't have any
>> more specific ideas at this point, though. If it turns out that the
>> decorators don't add significantly to the startup time, then the question of
>> alternatives is moot.
> 
> While this is not impossible, it would make my building of the docs
> more complicated, because there I rely on the runtime "hardcopy" rc
> property to format rest docstrings. I could do a special installation
> for doc building if it makes everyone else in the world's mpl loads
> 100x faster :-)
> 
> JDH
I tested the startup time for r7480 before and after the patch, and the 
difference is quite small--of the order of a percent--so I have no 
objection to the patch on that account. Or, for that matter, on any 
other account. I would not object to applying it (or a modification, if 
there is still fine-tuning to be done) to the trunk. It seems to work 
fine. John, I assume you have tested doc building with the patch in 
place. I have not.
Eric

Hi Jeff,
>
> You are using the macosx backend. Can you try another backend, say TkAgg,
> by running:
>
> python test.py -dTkAgg ??
>
> -Jeff
tried that as well - it doesn't plot and produces the following traceback:
ASR:Desktop arokem$ python example.py -dTkAgg
Exception in Tkinter callback
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/lib-tk/Tkinter.py",
line 1414, in __call__
 return self.func(*args)
 File "/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
line 212, in resize
 self.show()
 File "/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
line 216, in draw
 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
 File "/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/backends/tkagg.py",
line 19, in blit
 tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode,
id(bbox_array))
TclError

On Thu, Aug 13, 2009 at 1:08 PM, Eric Firing<ef...@ha...> wrote:
> Ideally, all the docstring manipulations would be done once at the time of
> installation or of compilation to .pyc, not at every mpl startup. I think
> that doing it at compilation time is impossible, given python's fundamental
> design, so that leaves the installation time alternative. I don't have any
> more specific ideas at this point, though. If it turns out that the
> decorators don't add significantly to the startup time, then the question of
> alternatives is moot.
While this is not impossible, it would make my building of the docs
more complicated, because there I rely on the runtime "hardcopy" rc
property to format rest docstrings. I could do a special installation
for doc building if it makes everyone else in the world's mpl loads
100x faster :-)
JDH

Jason R. Coombs wrote:
> 
>> -----Original Message-----
>> From: Darren Dale [mailto:dsd...@gm...]
>>
>> On Thu, Aug 13, 2009 at 7:44 AM, John Hunter<jd...@gm...> wrote:
>>> On Wed, Aug 12, 2009 at 7:12 AM, John Hunter<jd...@gm...>
>> wrote:
>> I appreciate how much time has gone into the patch, but this impacts
>> so much code I think it is important to really nail the
>> implementation.
> 
> Agreed
> 
>> I think everything should be rolled up into a single
>> high level decorator if possible.
> 
> While I think this approach is useful for readability where a pattern is seen 
> repeated, trying to implement every matplotlib docstring manipulation into a 
> single, monolithic decorator has the potential to become messy. This is why 
> I've chosen to implement the same functionality in various components that can 
> (and should in some cases) be assembled into a single construct.
[...]
> From that, high-level decorators could be assembled with the appropriate 
> dedent behavior included as well.
Jason, John, Darren,
I am jumping in late, and with only superficial comments for the moment, 
at least. After scanning the latest patch and reading the emails up to 
this point, here are my reactions:
1) In general I like Jason's latest patch. It looks readable, flexible, 
and testable--but I haven't done any testing yet myself. I find the 
arguments in this email to which I am replying to be convincing, so I am 
in favor of Jason's modular approach rather than the monolithic 
alternative, to the extent that I understand both.
2) Question: how does this relate to all the work that Jouni did 
recently to fix pyplot docstrings?
3) Question: how does this affect startup time? Jouni tested two 
approaches to his work, and the decorator approach was significantly 
slower. I think that for many mpl applications (not to mention running 
backend_driver.py, which is already getting so slow as to deter its 
frequent use), startup time really matters. At one point, dedent was 
accounting for something like 30% of the overhead. Mike's optimization 
knocked it back to a tolerable level. (Avoiding dedent by keeping 
docstrings slid to the left in the source is not acceptable--it makes 
the source horrible to read.)
Ideally, all the docstring manipulations would be done once at the time 
of installation or of compilation to .pyc, not at every mpl startup. I 
think that doing it at compilation time is impossible, given python's 
fundamental design, so that leaves the installation time alternative. I 
don't have any more specific ideas at this point, though. If it turns 
out that the decorators don't add significantly to the startup time, 
then the question of alternatives is moot.
Eric

On Thu, Aug 13, 2009 at 11:54:56AM -0500, Dave Peterson wrote:
> That depends. When doing a "python setup.py install" where setup.py's
> setup() function is imported from setuptools instead of distutils, then
> the setuptools install command deactivates any other eggs in the python
> environment, installs a "distutils" style install of the project in
> question, creates an .egg-info file in the install directory which acts
> just like a .egg, and finally updates the easy-install.pth in that install
> directory to reflect that the new install is active.
> If the setup.py uses the setup() function from distutils, then none of
> that happens and Gael is right. Any previous install of matplotlib via
> setuptools will go to the front of the sys.path and the new install won't
> be seen.
matplotlib's setup.py does not import from setuptools, and I can't blame
them :p.
Gaël

On Tue, Aug 11, 2009 at 07:53:29PM -0400, Jack Sankey wrote:
> Sorry for spamming, but I have another addition to
> BlockingMouseInput.add_click, that fixes the problem of the graphics
> jumping around while ginputting. This makes it much easier to zoom in on
> an imshow() plot and click a bunch of points, for example (it used to zoom
> all the way out!):
Hey Jack,
If you cannot send an 'svn diff' of your changes, would you mind sending
the modified files all together? It is hard to review changes when
gathering them from various mails: so easy to forget a change.
Cheers,
Ga

John,
This seems like a good idea. I wanted to prove and vet the decorators first,
shake out any emergent issues, and then consider enhancements that the new
structure might enable.
While I was working through this, I was surprised when I saw how the kwdocd
was assembled from the various modules and magically seemed to have the
right values by the time the docstrings needed them... but after thinking
about it for a bit, it occurred to me that it probably works because when a
module depends on certain keys being present, it probably has already
imported the module that provides those keys. Therefore, synchronization
issues aren't really issues.
Would you like me to implement these suggestions?
Jason
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> 
> Another thing to consider while cleaning this up is to not just put
> the artist props into the kwdocd, but *anything* that needs
> interpolating. So we could have one docstring.interpd into which all
> keys 'Line2D', 'Patch', 'AvailableArrowstyles', 'PSD', 'scale_docs',
> etc... Right now we have a hodge-podge of doc interpolation strings,
> and it might make sense to simplify this by putting them all into a
> single interp dict that can be used anywhere in mpl.
> 
> Jason, I hope we don't exhaust you with these suggestions -- this will
> be a very nice cleanup and a big help for people using mpl in
> installers like py2exe which strip out docs with the optimization
> flags. But as Darren said we need to get this right and keep the
> interface as simple as possible while preserving all the current
> functionality. Thanks for all your efforts.
> 
> JDH

Also, functools requires Python 2.5. Matplotlib supports Python 2.4.
> -----Original Message-----
> From: Darren Dale [mailto:dsd...@gm...]
> Sent: Thursday, 13 August, 2009 10:52
> To: Gael Varoquaux
> Cc: John Hunter; matplotlib development list; Eric Firing
> Subject: Re: [matplotlib-devel] kwdoc processing with decorators
> 
> On Thu, Aug 13, 2009 at 10:24 AM, Gael
> Varoquaux<gae...@no...> wrote:
> >
> > I have not followed the conversation, so please forgive me if I am
> > talking bull**, but why are you not using functools.wraps? I have
> found
> > it is useful to make really sure that you are keeping all the
> > properties of a function that you want to decorate.
> 
> I am aware of functools.wraps and have used it myself. So far we are
> only modifying and returning the original function, not a wrapped
> version of the original, so functools.wraps is not necessary.
> 
> Darren
> 

> -----Original Message-----
> From: Darren Dale [mailto:dsd...@gm...]
>
> On Thu, Aug 13, 2009 at 7:44 AM, John Hunter<jd...@gm...> wrote:
> > On Wed, Aug 12, 2009 at 7:12 AM, John Hunter<jd...@gm...>
> wrote:
> I appreciate how much time has gone into the patch, but this impacts
> so much code I think it is important to really nail the
> implementation.
Agreed
> I think everything should be rolled up into a single
> high level decorator if possible.
While I think this approach is useful for readability where a pattern is seen 
repeated, trying to implement every matplotlib docstring manipulation into a 
single, monolithic decorator has the potential to become messy. This is why 
I've chosen to implement the same functionality in various components that can 
(and should in some cases) be assembled into a single construct.
> I offered a suggestion in the
> tracker. Consider:
>
> with_doc(*args, **kwargs):
> mod_doc(f):
> if args:
> if not isinstance(args[0], str):
> # inherit docstring from first argument
> inherit = args.pop(0).__doc__
> if f.__doc__ is None:
> f.__doc__ = inherit
> else:
> f.__doc__ = inherit + '\n\n' + f.__doc__
> if kwargs:
> # mapping interpolation
> f.__doc__ = f.__doc__ % kwargs
> if args:
> try:
> # inserting
> f.__doc__ = f.__doc__ % args
> except TypeError:
> # appending
> if f.__doc__ is None:
> f.__doc__ = ''
> f.__doc__ = f.__doc__ + '\n\n'+ '\n\n'.join(args)
> return f
> return mod_doc
I appreciate the suggested implementation. It helped inspire me with my 
submitted patch, which I believe meets the same goals (or can with some 
combination of some of the various decorators).
This suggested implementation however has a few drawbacks compared with the 
submitted patch.
1) The form doesn't reflect the function. mod_doc indicates that the 
documentation is being modified, but the function is implicit and has to be 
reverse-engineered from the code. On the other hand, docstring.copy copies a 
docstring, while docstring.Substitution performs substitution.
2) with_doc doesn't have a way to handle a mutable parameter set. That is, 
all of the **kwargs or *args (in the second usage) must be present at the time 
the decorator is created. In the case of the sub_args decorator in artist.py, 
this isn't suitable. It would be possible to just create a new decorator 
(i.e. with_doc(**artist.kwdocd)) every place of sub_args is used, but that 
violates the DRY principle. The sub_args mutable decorator, on the other hand, 
takes the place of artist.kwdocd by representing an object with purpose and 
not just kwdocd data structure.
3) with_doc allows for both keyword and positional argument substitution. 
This seems like a dangerous allowance.
4) Modular decorators can have delegated responsibility and be tested 
separately.
5) with_doc hard-codes separators ('\n\n') in multiple places and doesn't 
allow a different separator to be specified (if necessary).
6) The TypeError exception handler in the second usage of *args may trap more 
exceptions than desired.
7) As you mentioned, it doesn't handle dedent. It's not clear to me where 
dedent should be included in the logic to properly capture the needs of 
matplotlib.
8) with_doc is largely addressing issues specifically around matplotlib. The 
submitted patch provides reusable decorators which might be assembled in 
creative ways not yet conceived.
Please understand, I'm trying to explain why the current implementation is 
sound and not to criticize your contribution.
> I left out the dedentation for now, and it is untested. This can cover
> lots of ground, I think it can be chained on itself:
>
> @with_doc('append me', prepend='prepend me as well')
> @with_doc(other_method)
> @with_doc('prepend me %(prepend)s')
The current code allows
@docstring.Substitution(prepend='prepend me as well')
@docstring.Appender('append me', join='\n\n')
@docstring.copy(other_method)
@docstring.Appender('prepend me %(prepend)s', join='\n\n')
While slightly more verbose, the second technique communicates clearly what is 
happening and there's no implicit behavior going on (i.e. copy takes another 
method while Appender takes a string). The default join could be '\n\n', but 
I chose an empty string as default. If '\n\n' is more desirable, that could 
certainly be made the default.
> If it is not possible, or possible but messy because of dedentation or
> other reasons, to pack everything into a single high-level decorator,
> then maybe there should be a few like:
>
> inherit_doc(fun) overwrite or prepend with fun's docstring
This is essentially the purpose of docstring.copy.
> insert_doc(*args, **kwargs) interpolate
This is the behavior of docstring.Substitution (plus allows for mutable 
parameters).
> append_doc(*args)
This is docstring.Appender (except only allows one argument, and allows 
separator to be supplied). If multiple args are require for appending, that 
certainly could be implemented.
> but since these are high-level decorators, chaining decorators would
> result in repeated calls to dedent.
>From that, high-level decorators could be assembled with the appropriate 
dedent behavior included as well.

On Thu, Aug 13, 2009 at 11:46 AM, John Hunter<jd...@gm...> wrote:
> On Thu, Aug 13, 2009 at 9:12 AM, Darren Dale<dsd...@gm...> wrote:
>
> I don't think Jason is on the dev list, so I am CC-ing him. Please
> make sure he is CC-d on all other conversations in this thread.
>
>> I appreciate how much time has gone into the patch, but this impacts
>> so much code I think it is important to really nail the
>> implementation. I think everything should be rolled up into a single
>> high level decorator if possible. I offered a suggestion in the
>> tracker. Consider:
>
>
>> with_doc(*args, **kwargs):
>>  mod_doc(f):
>>    if args:
>>      if not isinstance(args[0], str):
>>        # inherit docstring from first argument
>>        inherit = args.pop(0).__doc__
>>        if f.__doc__ is None:
>>          f.__doc__ = inherit
>>        else:
>>          f.__doc__ = inherit + '\n\n' + f.__doc__
>>    if kwargs:
>>      # mapping interpolation
>>      f.__doc__ = f.__doc__ % kwargs
>>    if args:
>>      try:
>>        # inserting
>>        f.__doc__ = f.__doc__ % args
>>      except TypeError:
>>         # appending
>>         if f.__doc__ is None:
>>           f.__doc__ = ''
>>         f.__doc__ = f.__doc__ + '\n\n'+ '\n\n'.join(args)
>>    return f
>>  return mod_doc
>>
>> I left out the dedentation for now, and it is untested. This can cover
>> lots of ground, I think it can be chained on itself:
>>
>> @with_doc('append me', prepend='prepend me as well')
>> @with_doc(other_method)
>> @with_doc('prepend me %(prepend)s')
>>
>> If it is not possible, or possible but messy because of dedentation or
>> other reasons, to pack everything into a single high-level decorator,
>> then maybe there should be a few like:
>>
>> inherit_doc(fun) overwrite or prepend with fun's docstring
>> insert_doc(*args, **kwargs) interpolate
>> append_doc(*args)
>>
>> but since these are high-level decorators, chaining decorators would
>> result in repeated calls to dedent.
>
>
> Another thing to consider while cleaning this up is to not just put
> the artist props into the kwdocd, but *anything* that needs
> interpolating. So we could have one docstring.interpd into which all
> keys 'Line2D', 'Patch', 'AvailableArrowstyles', 'PSD', 'scale_docs',
> etc... Right now we have a hodge-podge of doc interpolation strings,
> and it might make sense to simplify this by putting them all into a
> single interp dict that can be used anywhere in mpl.
>
> Jason, I hope we don't exhaust you with these suggestions -- this will
> be a very nice cleanup and a big help for people using mpl in
> installers like py2exe which strip out docs with the optimization
> flags. But as Darren said we need to get this right and keep the
> interface as simple as possible while preserving all the current
> functionality. Thanks for all your efforts.
It suggest hashing out the basic approach and interface on the list
before applying it throughout the library.
Darren
-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is
possible, relations between the manifold aspects of our experience" -
Niels Bohr
"It is a bad habit of physicists to take their most successful
abstractions to be real properties of our world." - N. David Mermin
"Once we have granted that any physical theory is essentially only a
model for the world of experience, we must renounce all hope of
finding anything like the correct theory ... simply because the
totality of experience is never accessible to us." - Hugh Everett III

Gael Varoquaux wrote:
> On Thu, Aug 13, 2009 at 09:30:22AM -0600, Jeff Whitaker wrote:
> 
>> Ariel Rokem wrote
>>>>>> import matplotlib
>>>>>> matplotlib.__version__
>>>>>> 
>>> '0.98.5.2'
>>> 
>> Ariel: This tells me you really didn't install it, or you installed it 
>> in a different version of python than you are trying to import it with.
>> 
>>> So - still no version update. I ran:
>>> 
>>> 'easy_install matplotlib', which somehow seems to change the path
>>> setting to find the most recent version of things (maybe someone here
>>> can tell me how this happens?) now:
>>> 
>
>
> I am not sure that Ariel didn't install things right. He might be a
> victim of setuptools' monkey patching of sys.path.
That depends. When doing a "python setup.py install" where setup.py's 
setup() function is imported from setuptools instead of distutils, then 
the setuptools install command deactivates any other eggs in the python 
environment, installs a "distutils" style install of the project in 
question, creates an .egg-info file in the install directory which acts 
just like a .egg, and finally updates the easy-install.pth in that 
install directory to reflect that the new install is active.
If the setup.py uses the setup() function from distutils, then none of 
that happens and Gael is right. Any previous install of matplotlib via 
setuptools will go to the front of the sys.path and the new install 
won't be seen.
-- Dave

On Thu, Aug 13, 2009 at 09:30:22AM -0600, Jeff Whitaker wrote:
> Ariel Rokem wrote:
> > Resending with CC to list:
> > D'oh. I forgot to do that. OK - now I went back and ran:
> > env ARCHFLAGS='-arch i386' python setup.py install
> > That also went with no hitches
> > Then, in Python:
> >>>> import matplotlib
> >>>> matplotlib.__version__
> > '0.98.5.2'
> Ariel: This tells me you really didn't install it, or you installed it 
> in a different version of python than you are trying to import it with.
> > So - still no version update. I ran:
> > 'easy_install matplotlib', which somehow seems to change the path
> > setting to find the most recent version of things (maybe someone here
> > can tell me how this happens?) now:
I am not sure that Ariel didn't install things right. He might be a
victim of setuptools' monkey patching of sys.path. Ariel, you should go
around in the various easy_install.pth in the different folder on you
Python path (that is the system ones as well as the ones in your
$PYTHONPATH) and make sure that any reference to matplotlib is removed.
Gaël

Ariel Rokem wrote:
> Hi Jeff,
>
> 
>>>>>> import matplotlib
>>>>>> matplotlib.__version__
>>>>>>
>>>>>> 
>>> '0.98.5.2'
>>>
>>> 
>> Ariel: This tells me you really didn't install it, or you installed it in a
>> different version of python than you are trying to import it with.
>> 
>
> That does sound reasonable - but how do you explain what followed?
> 
Ariel:
I don't pretend to understand how setuptools works.
> 
>>> So - still no version update. I ran:
>>>
>>> 'easy_install matplotlib', which somehow seems to change the path
>>> setting to find the most recent version of things (maybe someone here
>>> can tell me how this happens?) now:
>>>
>>>
>>> 
>>>>>> import matplotlib
>>>>>> matplotlib.__version__
>>>>>>
>>>>>> 
>>> '0.99.0'
>>> 
>
>
>
> 
>> We'll need more details on this one - a simple script that triggers it and
>> what backend you're using, for starters.
>>
>> 
>
> Here's a simple script that triggers this behavior:
>
> from matplotlib import pylab
> pylab.plot([0,1])
> pylab.show()
>
> When I run that from ipython, it hangs and doesn't respond to attempts
> to keyboard interrupt.
>
> When I run it from the terminal it also hangs, running it with
> --verbose-helpful, I get:
>
> backend MacOSX version unknown
>
> Is there another way to figure out which backend is being used?
>
> Cheers,
>
> Ariel
> 
You are using the macosx backend. Can you try another backend, say 
TkAgg, by running:
python test.py -dTkAgg ??
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hi Jeff,
>>>>> import matplotlib
>>>>> matplotlib.__version__
>>>>>
>>
>> '0.98.5.2'
>>
>
> Ariel: This tells me you really didn't install it, or you installed it in a
> different version of python than you are trying to import it with.
That does sound reasonable - but how do you explain what followed?
>> So - still no version update. I ran:
>>
>> 'easy_install matplotlib', which somehow seems to change the path
>> setting to find the most recent version of things (maybe someone here
>> can tell me how this happens?) now:
>>
>>
>>>>>
>>>>> import matplotlib
>>>>> matplotlib.__version__
>>>>>
>>
>> '0.99.0'
> We'll need more details on this one - a simple script that triggers it and
> what backend you're using, for starters.
>
Here's a simple script that triggers this behavior:
from matplotlib import pylab
pylab.plot([0,1])
pylab.show()
When I run that from ipython, it hangs and doesn't respond to attempts
to keyboard interrupt.
When I run it from the terminal it also hangs, running it with
--verbose-helpful, I get:
backend MacOSX version unknown
Is there another way to figure out which backend is being used?
Cheers,
Ariel

On Thu, Aug 13, 2009 at 9:12 AM, Darren Dale<dsd...@gm...> wrote:
I don't think Jason is on the dev list, so I am CC-ing him. Please
make sure he is CC-d on all other conversations in this thread.
> I appreciate how much time has gone into the patch, but this impacts
> so much code I think it is important to really nail the
> implementation. I think everything should be rolled up into a single
> high level decorator if possible. I offered a suggestion in the
> tracker. Consider:
> with_doc(*args, **kwargs):
>  mod_doc(f):
>    if args:
>      if not isinstance(args[0], str):
>        # inherit docstring from first argument
>        inherit = args.pop(0).__doc__
>        if f.__doc__ is None:
>          f.__doc__ = inherit
>        else:
>          f.__doc__ = inherit + '\n\n' + f.__doc__
>    if kwargs:
>      # mapping interpolation
>      f.__doc__ = f.__doc__ % kwargs
>    if args:
>      try:
>        # inserting
>        f.__doc__ = f.__doc__ % args
>      except TypeError:
>         # appending
>         if f.__doc__ is None:
>           f.__doc__ = ''
>         f.__doc__ = f.__doc__ + '\n\n'+ '\n\n'.join(args)
>    return f
>  return mod_doc
>
> I left out the dedentation for now, and it is untested. This can cover
> lots of ground, I think it can be chained on itself:
>
> @with_doc('append me', prepend='prepend me as well')
> @with_doc(other_method)
> @with_doc('prepend me %(prepend)s')
>
> If it is not possible, or possible but messy because of dedentation or
> other reasons, to pack everything into a single high-level decorator,
> then maybe there should be a few like:
>
> inherit_doc(fun) overwrite or prepend with fun's docstring
> insert_doc(*args, **kwargs) interpolate
> append_doc(*args)
>
> but since these are high-level decorators, chaining decorators would
> result in repeated calls to dedent.
Another thing to consider while cleaning this up is to not just put
the artist props into the kwdocd, but *anything* that needs
interpolating. So we could have one docstring.interpd into which all
keys 'Line2D', 'Patch', 'AvailableArrowstyles', 'PSD', 'scale_docs',
etc... Right now we have a hodge-podge of doc interpolation strings,
and it might make sense to simplify this by putting them all into a
single interp dict that can be used anywhere in mpl.
Jason, I hope we don't exhaust you with these suggestions -- this will
be a very nice cleanup and a big help for people using mpl in
installers like py2exe which strip out docs with the optimization
flags. But as Darren said we need to get this right and keep the
interface as simple as possible while preserving all the current
functionality. Thanks for all your efforts.
JDH

Ariel Rokem wrote:
> Resending with CC to list:
>
> D'oh. I forgot to do that. OK - now I went back and ran:
>
> env ARCHFLAGS='-arch i386' python setup.py install
>
> That also went with no hitches
>
> Then, in Python:
>
> 
>>>> import matplotlib
>>>> matplotlib.__version__
>>>> 
> '0.98.5.2'
> 
Ariel: This tells me you really didn't install it, or you installed it 
in a different version of python than you are trying to import it with.
> So - still no version update. I ran:
>
> 'easy_install matplotlib', which somehow seems to change the path
> setting to find the most recent version of things (maybe someone here
> can tell me how this happens?) now:
>
> 
>>>> import matplotlib
>>>> matplotlib.__version__
>>>> 
> '0.99.0'
>
> However, now, when I run a script that has plotting in it, in ipython,
> the script hangs after plotting. That is, it puts up the first figure
> in the script (a simple bar graph) and then doesn't do anything more.
> So - on the one hand, it doesn't crash while building and installing.
> On the other hand, it doesn't work.
> 
We'll need more details on this one - a simple script that triggers it 
and what backend you're using, for starters.
-Jeff
> Cheers,
>
> Ariel
>
> On Thu, Aug 13, 2009 at 5:19 AM, Jeff Whitaker<js...@fa...> wrote:
> 
>> Ariel Rokem wrote:
>> 
>>> Hi - that's interesting - I am actually on OS10.5. For some reason,
>>> the MPL libraries get built under a directory called
>>> "lib.macosx-10.3-fat-2.5" and the SDK set in the Python Makefile is
>>> /Developer/SDKs/MacOSX10.4u.sdk, which is why you see these mentioned
>>> in the output.
>>>
>>> Wondering if that is the cause of the problems, I reset the SDK in the
>>> Makefile to /Developer/SDKs/MacOSX10.5.sdk (in the definition of
>>> BASECFLAGS, as well as LDFLAGS). As before, I removed the '-arch ppc'
>>> (from these two places, as well) and ran 'env ARCHFLAGS='-arch i386'
>>> python setup.py build'
>>>
>>> This time I don't get any compilation errors at all. It just runs
>>> through. However, when I import matplotlib in python, I still get:
>>>
>>> 
>> Ariel: Did you run 'python setup.py install'?
>>
>> -Jeff
>>
>>
>> 
>
>
>
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Resending with CC to list:
D'oh. I forgot to do that. OK - now I went back and ran:
env ARCHFLAGS='-arch i386' python setup.py install
That also went with no hitches
Then, in Python:
>>> import matplotlib
>>> matplotlib.__version__
'0.98.5.2'
So - still no version update. I ran:
'easy_install matplotlib', which somehow seems to change the path
setting to find the most recent version of things (maybe someone here
can tell me how this happens?) now:
>>> import matplotlib
>>> matplotlib.__version__
'0.99.0'
However, now, when I run a script that has plotting in it, in ipython,
the script hangs after plotting. That is, it puts up the first figure
in the script (a simple bar graph) and then doesn't do anything more.
So - on the one hand, it doesn't crash while building and installing.
On the other hand, it doesn't work.
Cheers,
Ariel
On Thu, Aug 13, 2009 at 5:19 AM, Jeff Whitaker<js...@fa...> wrote:
> Ariel Rokem wrote:
>>
>> Hi - that's interesting - I am actually on OS10.5. For some reason,
>> the MPL libraries get built under a directory called
>> "lib.macosx-10.3-fat-2.5" and the SDK set in the Python Makefile is
>> /Developer/SDKs/MacOSX10.4u.sdk, which is why you see these mentioned
>> in the output.
>>
>> Wondering if that is the cause of the problems, I reset the SDK in the
>> Makefile to /Developer/SDKs/MacOSX10.5.sdk (in the definition of
>> BASECFLAGS, as well as LDFLAGS). As before, I removed the '-arch ppc'
>> (from these two places, as well) and ran 'env ARCHFLAGS='-arch i386'
>> python setup.py build'
>>
>> This time I don't get any compilation errors at all. It just runs
>> through. However, when I import matplotlib in python, I still get:
>>
>
> Ariel: Did you run 'python setup.py install'?
>
> -Jeff
>
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

On Thu, Aug 13, 2009 at 10:52:24AM -0400, Darren Dale wrote:
> I am aware of functools.wraps and have used it myself. So far we are
> only modifying and returning the original function, not a wrapped
> version of the original, so functools.wraps is not necessary.
OK, as I suspected, I was not reading the code properly.
Thanks for your answer.
Gaël

Hi Gael,
On Thu, Aug 13, 2009 at 10:24 AM, Gael
Varoquaux<gae...@no...> wrote:
> On Thu, Aug 13, 2009 at 10:12:23AM -0400, Darren Dale wrote:
>> I appreciate how much time has gone into the patch, but this impacts
>> so much code I think it is important to really nail the
>> implementation. I think everything should be rolled up into a single
>> high level decorator if possible. I offered a suggestion in the
>> tracker. Consider:
>
>> with_doc(*args, **kwargs):
>>   mod_doc(f):
>>     if args:
>>       if not isinstance(args[0], str):
>>         # inherit docstring from first argument
>>         inherit = args.pop(0).__doc__
>>         if f.__doc__ is None:
>>           f.__doc__ = inherit
>>         else:
>>           f.__doc__ = inherit + '\n\n' + f.__doc__
>>     if kwargs:
>>       # mapping interpolation
>>       f.__doc__ = f.__doc__ % kwargs
>>     if args:
>>       try:
>>         # inserting
>>         f.__doc__ = f.__doc__ % args
>>       except TypeError:
>>         # appending
>>         if f.__doc__ is None:
>>           f.__doc__ = ''
>>         f.__doc__ = f.__doc__ + '\n\n'+ '\n\n'.join(args)
>>     return f
>>   return mod_doc
>
> I have not followed the conversation, so please forgive me if I am
> talking bull**, but why are you not using functools.wraps? I have found
> it is useful to make really sure that you are keeping all the
> properties of a function that you want to decorate.
I am aware of functools.wraps and have used it myself. So far we are
only modifying and returning the original function, not a wrapped
version of the original, so functools.wraps is not necessary.
Darren

On Thu, Aug 13, 2009 at 10:12:23AM -0400, Darren Dale wrote:
> I appreciate how much time has gone into the patch, but this impacts
> so much code I think it is important to really nail the
> implementation. I think everything should be rolled up into a single
> high level decorator if possible. I offered a suggestion in the
> tracker. Consider:
> with_doc(*args, **kwargs):
> mod_doc(f):
> if args:
> if not isinstance(args[0], str):
> # inherit docstring from first argument
> inherit = args.pop(0).__doc__
> if f.__doc__ is None:
> f.__doc__ = inherit
> else:
> f.__doc__ = inherit + '\n\n' + f.__doc__
> if kwargs:
> # mapping interpolation
> f.__doc__ = f.__doc__ % kwargs
> if args:
> try:
> # inserting
> f.__doc__ = f.__doc__ % args
> except TypeError:
> # appending
> if f.__doc__ is None:
> f.__doc__ = ''
> f.__doc__ = f.__doc__ + '\n\n'+ '\n\n'.join(args)
> return f
> return mod_doc
I have not followed the conversation, so please forgive me if I am
talking bull**, but why are you not using functools.wraps? I have found
it is useful to make really sure that you are keeping all the
properties of a function that you want to decorate.
Gaël
PS: Some of the mayavi codebase should be changed to use wraps, so don't
take this as a blame, but more as a question :).