matplotlib-devel Mailing List for matplotlib

Jason R. Coombs wrote:
> It appears that the docstring.py module somehow got omitted from the rev5
> patch (I was working from two different machines, and one didn't have it
> added to SVN).
> 
> So I'm attaching missing_docstring.patch which is a patch against the latest
> trunk to include the latest version of docstring.py. It's functionally the
> same as the version that Eric has tested against in rev 4, but a
> documentation string has changed in the last method.
> 
> Sorry for the mixup.
> 
> Jason
Thank you. When I committed the rev5 patch earlier, I did not notice 
that I needed to do "svn add docstring.py", so it was not included at 
all. Now I think everything is in place, as of 7496.
Eric

It appears that the docstring.py module somehow got omitted from the rev5
patch (I was working from two different machines, and one didn't have it
added to SVN).
So I'm attaching missing_docstring.patch which is a patch against the latest
trunk to include the latest version of docstring.py. It's functionally the
same as the version that Eric has tested against in rev 4, but a
documentation string has changed in the last method.
Sorry for the mixup.
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 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

John Hunter <jd...@gm...> writes:
> Would you like to take a crack at these fixes? [...] I would be happy
> to get as many fixes and patches in next week and try to get one
> bugfix 0.99.1 out before scipy.
I started fixing the issues. It's not complete yet, but the current
state should be usable. However, this work is not on the 0.99 branch,
only on the trunk.
Handling the off-line use case is harder than I thought: at least on my
laptop the urlopen call just blocks, so there needs to be a timeout
mechanism.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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