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 prob
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:
gr...@tiny:~/sage/local/lib/python2.6/site-packages/matplotlib$ grep -r
transAxis *
axis.py:*
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 t
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
jason-s...@creativetrax.com wrote:
> In the documentation for the Axis object, I see that there is supposed
> to be a transAxis attr
jason-s...@creativetrax.com wrote:
> On this thread:
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/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
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
=
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', Depre
Eric Firing 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 i
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:efir...@hawaii.edu]
Sent: Thursday, 13 August, 2009 21:33
To: Jason R. Coombs
Cc: matplotlib development list
Subject: R
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 loo
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-ne
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
Andrew Straw wrote:
> jason-s...@creativetrax.com wrote:
>
>> On this thread:
>>
>> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/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
13 matches
Mail list logo
