matplotlib-devel Mailing List for matplotlib (Page 6)

Andrew Straw wrote:
> jas...@cr... wrote:
>   
>> On this thread:
>>
>> http://www.mail-archive.com/mat...@li.../msg05383.html
>>
>> clip_on was a suggested way of getting around the clipping that happens 
>> at the edge of a frame.  In the Sage project, we are always setting the 
>> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
>> the lines and circles that pass across the edge of the usual clip 
>> boundary to still be drawn, even if we have set the xlim and ylim of the 
>> axis?
>>
>> Basically (using an example from the gallery), is there a way to get the 
>> scatter plot circles below not clipped, while still having the y-axis 
>> only go from -2 to 2?  If not, is there a way to easily calculate the 
>> protrusion of the various objects, like the circles below, so we know 
>> how much to adjust the axes to just include the circles?
>>   
>>     
> Another idea would be to disable clipping specifically for any markers
> at xlim[0] <= markerx <= xlim[1].
>
> I'll talk about this with John and other interested parties at the SciPy
> conference (will you be there?) and hopefully address this issue during
> the sprint, where I'm planning to work on MPL.
>
>   

No, I won't be there, but I'm excited to hear what comes out of the sprint.

Andrew, thanks for suggesting a way to get this to work.  Michael and 
Eric, thanks for finding a fix for the general problem.

I'm impressed at how quickly developers respond to questions here!  I am 
really, really glad that Sage is using matplotlib for 2d graphics.

Thanks,

Jason

Thanks again for pointing out the issue (to my embarrassment).

The rev5 patch addresses the issue. I had missed an essential parameter in
pyplot.autogen_docstring.  I've tested this new patch, and I'm able to call
help(pyplot.plot) and execute pyplot.plot([1,2]) without any errors.  I
believe this corrects the issue.

Please let me know if you encounter any additional issues.

Regards,
Jason

-----Original Message-----
From: Eric Firing [mailto:ef...@ha...] 
Sent: Thursday, 13 August, 2009 21:33
To: Jason R. Coombs
Cc: matplotlib development list
Subject: Re: [matplotlib-devel] kwdoc processing with decorators

Jason,

There is a problem with rev4, running "ipython -pylab":

Hi,

There are a few new features I have committed into the svn. Nothing
significant, but hopefully useful (and fun to play with). Here is a
quick summary with screenshots ( I made a separate page because it
involves number of images).

http://abitofpythonabitofastronomy.blogspot.com/2009/08/few-new-things-in-mpl-svn.html

Give them a try when you have a chance. The api is still experimental
and any suggestion will be welcomed. On the other hand, I needed to
make some minor changes to the existing code. While I hope it does not
break any, let me know if anything odd happens.

Regards,

-JJ

Michael Droettboom wrote:
> I think this is just a vanilla bug that set_clip_on is being ignored for 
> collections.  That patch is rather straightforward.
> 
> Other developers: do you agree this should be fixed, or is there a good 
> reason for current behavior that I'm missing?

It certainly looks to me like an annoying bug, so if your patch fixes 
it, great!

Eric

> 
> Cheers,
> Mike
> 
> Index: lib/matplotlib/collections.py
> ===================================================================
> --- lib/matplotlib/collections.py       (revision 7486)
> +++ lib/matplotlib/collections.py       (working copy)
> @@ -207,8 +207,7 @@
>          transform, transOffset, offsets, paths = self._prepare_points()
> 
>          gc = renderer.new_gc()
> -        gc.set_clip_rectangle(self.get_clip_box())
> -        gc.set_clip_path(self.get_clip_path())
> +        self._set_gc_clip(gc)
> 
>          renderer.draw_path_collection(
>              gc, transform.frozen(), paths, self.get_transforms(),
> @@ -1211,8 +1210,7 @@
>              transOffset = transOffset.get_affine()
> 
>          gc = renderer.new_gc()
> -        gc.set_clip_rectangle(self.get_clip_box())
> -        gc.set_clip_path(self.get_clip_path())
> +        self._set_gc_clip(gc)
> 
>          if self._shading == 'gouraud':
>              triangles, colors = self.convert_mesh_to_triangles(
> 
> 
> jas...@cr... wrote:
>> On this thread:
>>
>> http://www.mail-archive.com/mat...@li.../msg05383.html
>>
>> clip_on was a suggested way of getting around the clipping that happens 
>> at the edge of a frame.  In the Sage project, we are always setting the 
>> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
>> the lines and circles that pass across the edge of the usual clip 
>> boundary to still be drawn, even if we have set the xlim and ylim of the 
>> axis?
>>
>> Basically (using an example from the gallery), is there a way to get the 
>> scatter plot circles below not clipped, while still having the y-axis 
>> only go from -2 to 2?  If not, is there a way to easily calculate the 
>> protrusion of the various objects, like the circles below, so we know 
>> how much to adjust the axes to just include the circles?
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>> fig = plt.figure()
>> x = np.linspace(0r,2*np.pi,100r)
>> y = 2*np.sin(x)
>> ax = fig.add_subplot(1,1,1)
>> q=ax.scatter(x,y)
>> ax.set_ylim([-2,2])
>> q.set_clip_on(False)
>> ax.set_clip_on(False)
>> ax.spines['left'].set_position(('outward',10))
>> ax.spines['bottom'].set_position(('outward',10))
>> ax.spines['top'].set_color('none')
>> ax.spines['right'].set_color('none')
>> ax.xaxis.set_ticks_position('bottom')
>> ax.yaxis.set_ticks_position('left')
>> fig.savefig('test.png')
>>
>> Thanks,
>>
>> Jason
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>   
> 

Oh, so you want _everything_ to work after the patch?  GG

Thanks for reporting this.  I'll track it down and get it fixed.

-----Original Message-----
From: Eric Firing [mailto:ef...@ha...] 
Sent: Thursday, 13 August, 2009 21:33
To: Jason R. Coombs
Cc: matplotlib development list
Subject: Re: [matplotlib-devel] kwdoc processing with decorators

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,

There is a problem with rev4, running "ipython -pylab":

In [1]:plot([1,2])
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/efiring/<ipython console> in <module>()

/usr/local/lib/python2.6/dist-packages/matplotlib/docstring.pyc in 
<lambda>(target)
     334         # language" - GVR. I think functools might help when 
Python 2.5

     335         # is required.

--> 336         return lambda target: dedent(copy(source)(target))
     337 from matplotlib import cbook
     338

/usr/local/lib/python2.6/dist-packages/matplotlib/docstring.pyc in 
do_copy(target)
     422     def do_copy(target):
     423         if source.__doc__:
--> 424             target.__doc__ = source.__doc__
     425         return target
     426     return do_copy

AttributeError: 'list' object attribute '__doc__' is read-only


Eric

Eric Firing <ef...@ha...> writes:

> 3) Question: how does this affect startup time?  Jouni tested two 
> approaches to his work, and the decorator approach was significantly 
> slower.  

No, actually the difference was barely measurable. The reason I chose
the boilerplate approach of generating source files instead of using
magic wrappers to generate functions at runtime was that I thought the
latter were too magical - difficult to get right, and probably more
difficult to debug when something breaks.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I just happened to type getp(gca()) on matplotlib 0.99.0, and the output
looks all garbled:

>>> getp(gca())
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/axes.py:1269: DeprecationWarning: use ax.patch instead
  warnings.warn('use ax.patch instead', DeprecationWarning)
    stable = box
    a = 1.0
    or = C
    ated = False
    ct = auto
    scale_on = True
    scalex_on = True
    scaley_on = True
     = Axes(0.125,0.1;0.775x0.8)
    _locator = None
    _bgcolor = w
[...]

It's been a long time since I last tried this, but does anyone have an
idea what changes could have caused this? Could it be related to the
ReST formatting in the docstrings?

Querying single attributes as in getp(gca(), 'yscale') seems to work
fine, it's just this listing of all attributes that seems to be broken.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I think this is just a vanilla bug that set_clip_on is being ignored for 
collections.  That patch is rather straightforward.

Other developers: do you agree this should be fixed, or is there a good 
reason for current behavior that I'm missing?

Cheers,
Mike

Index: lib/matplotlib/collections.py
===================================================================
--- lib/matplotlib/collections.py       (revision 7486)
+++ lib/matplotlib/collections.py       (working copy)
@@ -207,8 +207,7 @@
         transform, transOffset, offsets, paths = self._prepare_points()

         gc = renderer.new_gc()
-        gc.set_clip_rectangle(self.get_clip_box())
-        gc.set_clip_path(self.get_clip_path())
+        self._set_gc_clip(gc)

         renderer.draw_path_collection(
             gc, transform.frozen(), paths, self.get_transforms(),
@@ -1211,8 +1210,7 @@
             transOffset = transOffset.get_affine()

         gc = renderer.new_gc()
-        gc.set_clip_rectangle(self.get_clip_box())
-        gc.set_clip_path(self.get_clip_path())
+        self._set_gc_clip(gc)

         if self._shading == 'gouraud':
             triangles, colors = self.convert_mesh_to_triangles(


jas...@cr... wrote:
> On this thread:
>
> http://www.mail-archive.com/mat...@li.../msg05383.html
>
> clip_on was a suggested way of getting around the clipping that happens 
> at the edge of a frame.  In the Sage project, we are always setting the 
> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
> the lines and circles that pass across the edge of the usual clip 
> boundary to still be drawn, even if we have set the xlim and ylim of the 
> axis?
>
> Basically (using an example from the gallery), is there a way to get the 
> scatter plot circles below not clipped, while still having the y-axis 
> only go from -2 to 2?  If not, is there a way to easily calculate the 
> protrusion of the various objects, like the circles below, so we know 
> how much to adjust the axes to just include the circles?
>
> import matplotlib.pyplot as plt
> import numpy as np
> fig = plt.figure()
> x = np.linspace(0r,2*np.pi,100r)
> y = 2*np.sin(x)
> ax = fig.add_subplot(1,1,1)
> q=ax.scatter(x,y)
> ax.set_ylim([-2,2])
> q.set_clip_on(False)
> ax.set_clip_on(False)
> ax.spines['left'].set_position(('outward',10))
> ax.spines['bottom'].set_position(('outward',10))
> ax.spines['top'].set_color('none')
> ax.spines['right'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png')
>
> Thanks,
>
> Jason
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

jas...@cr... wrote:
> On this thread:
>
> http://www.mail-archive.com/mat...@li.../msg05383.html
>
> clip_on was a suggested way of getting around the clipping that happens 
> at the edge of a frame.  In the Sage project, we are always setting the 
> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
> the lines and circles that pass across the edge of the usual clip 
> boundary to still be drawn, even if we have set the xlim and ylim of the 
> axis?
>
> Basically (using an example from the gallery), is there a way to get the 
> scatter plot circles below not clipped, while still having the y-axis 
> only go from -2 to 2?  If not, is there a way to easily calculate the 
> protrusion of the various objects, like the circles below, so we know 
> how much to adjust the axes to just include the circles?
>   
Another idea would be to disable clipping specifically for any markers
at xlim[0] <= markerx <= xlim[1].

I'll talk about this with John and other interested parties at the SciPy
conference (will you be there?) and hopefully address this issue during
the sprint, where I'm planning to work on MPL.

-Andrew

It is now stored in the parent Axes object.

  axis.axes.transAxes

Same is true of transData.

Thanks for pointing this out.  I will update the docs.

Cheers,
Mike

jas...@cr... wrote:
> In the documentation for the Axis object, I see that there is supposed 
> to be a transAxis attribute.  However, when grepping for it in the 
> source, the only place it appears is in the documentation:
>
> grout@tiny:~/sage/local/lib/python2.6/site-packages/matplotlib$ grep -r 
> transAxis *
> axis.py:    * :attr:`transAxis` - transform axis coords to display coords
> Binary file axis.pyc matches
>
>
> Has this attribute been removed?  This is with version 0.99.0.
>
> Thanks,
>
> Jason
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

This is a great idea, Eric.  I don't think this is a SF bug, as I recall 
having seen this many since I "got here".  I've usually just stopped 
looking before the 0.91 release or so.  But you're right -- let's clean 
this stuff out.

I've cleaned out a few already, but are there any takers for me to 
assign Mac-specific and Windows-specific bugs?  I'm happy to take any 
Linux-specific ones.

Cheers,
Mike

Eric Firing wrote:
> After ignoring it for a long time, I took a look at the Sourceforge bug 
> tracker, and closed a couple bugs.  Our bug list is a bit embarrassing; 
> there are 52 open ones going back to 2005.  Is any of this an artifact 
> of all the reworking going on at SF?  Did some closed bugs get reopened 
> by accident?  In any case, it would be nice to get the list of open bugs 
> down to a much smaller number, and ensure that the oldest is not very 
> old.  I suspect many of the old ones have long since either been fixed 
> or rendered irrelevant by other changes.
>
> For all reading this list: even if you don't have mpl svn commit access, 
> if you can review a bug and propose a fix, or conclude it is obsolete, 
> or provide some other way of moving us towards getting it closed, your 
> effort would be much appreciated.
>
> Thank you.
>
> Eric
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

In the documentation for the Axis object, I see that there is supposed 
to be a transAxis attribute.  However, when grepping for it in the 
source, the only place it appears is in the documentation:

grout@tiny:~/sage/local/lib/python2.6/site-packages/matplotlib$ grep -r 
transAxis *
axis.py:    * :attr:`transAxis` - transform axis coords to display coords
Binary file axis.pyc matches


Has this attribute been removed?  This is with version 0.99.0.

Thanks,

Jason

I just noticed that the following two functions seem inconsistent:

axes.get_xticklabels has a "minor" argument, which defaults to False

However, axes.get_xticklines has no such argument, so in order to get 
the minor ticklines, one has to go down to the axes.xaxis object.  This 
isn't a huge problem, but the inconsistency seems a little odd.  Can we 
make a minor argument for axes.get_xticklines?

Thanks,

Jason

On this thread:

http://www.mail-archive.com/mat...@li.../msg05383.html

clip_on was a suggested way of getting around the clipping that happens 
at the edge of a frame.  In the Sage project, we are always setting the 
limits on the axes via set_xlim and set_ylim.  Is there any way to get 
the lines and circles that pass across the edge of the usual clip 
boundary to still be drawn, even if we have set the xlim and ylim of the 
axis?

Basically (using an example from the gallery), is there a way to get the 
scatter plot circles below not clipped, while still having the y-axis 
only go from -2 to 2?  If not, is there a way to easily calculate the 
protrusion of the various objects, like the circles below, so we know 
how much to adjust the axes to just include the circles?

import matplotlib.pyplot as plt
import numpy as np
fig = plt.figure()
x = np.linspace(0r,2*np.pi,100r)
y = 2*np.sin(x)
ax = fig.add_subplot(1,1,1)
q=ax.scatter(x,y)
ax.set_ylim([-2,2])
q.set_clip_on(False)
ax.set_clip_on(False)
ax.spines['left'].set_position(('outward',10))
ax.spines['bottom'].set_position(('outward',10))
ax.spines['top'].set_color('none')
ax.spines['right'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png')

Thanks,

Jason

After ignoring it for a long time, I took a look at the Sourceforge bug 
tracker, and closed a couple bugs.  Our bug list is a bit embarrassing; 
there are 52 open ones going back to 2005.  Is any of this an artifact 
of all the reworking going on at SF?  Did some closed bugs get reopened 
by accident?  In any case, it would be nice to get the list of open bugs 
down to a much smaller number, and ensure that the oldest is not very 
old.  I suspect many of the old ones have long since either been fixed 
or rendered irrelevant by other changes.

For all reading this list: even if you don't have mpl svn commit access, 
if you can review a bug and propose a fix, or conclude it is obsolete, 
or provide some other way of moving us towards getting it closed, your 
effort would be much appreciated.

Thank you.

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,

There is a problem with rev4, running "ipython -pylab":

In [1]:plot([1,2])
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/efiring/<ipython console> in <module>()

/usr/local/lib/python2.6/dist-packages/matplotlib/docstring.pyc in 
<lambda>(target)
     334         # language" - GVR. I think functools might help when 
Python 2.5

     335         # is required.

--> 336         return lambda target: dedent(copy(source)(target))
     337 from matplotlib import cbook
     338

/usr/local/lib/python2.6/dist-packages/matplotlib/docstring.pyc in 
do_copy(target)
     422     def do_copy(target):
     423         if source.__doc__:
--> 424             target.__doc__ = source.__doc__
     425         return target
     426     return do_copy

AttributeError: 'list' object attribute '__doc__' is read-only


Eric

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