I just thought of a possible interaction issue that might have to be sorted
out. If we want a .set_xlim() to firmly establish the data limits, what
about a future (or previous) call to ax.set_aspect('equal', 'datalim')?
This causes the data limits to change within the figure box.
Ben Root
On
John Hunter wrote:
On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote:
The issue was related with the change in Sphinx v1.0b2, which I think
I fixed in r8447.
At least, the html are built fine and uploaded fine.
However, the link to trunk-docs still does not work.
On Jun 29, 2010, at 5:08 PM, Andrew Straw straw...@astraw.com wrote:
John Hunter wrote:
On Sun, Jun 20, 2010 at 7:56 PM,
However, the link to trunk-docs still does not work.
http://matplotlib.sourceforge.net/trunk-docs/
I believe I fixed the issue in svn r8477.
Now, to fix the
My understanding is that the proposed change will break at least some
existing code, hence my proposal to go the safer route.
Also I'm unconvinced by the justification for the change :
xlim and autoscalex_on are independant attributes, why then should setting
xlim have the side effect of turning
On Tue, 2010-06-29 at 15:32 -0500, Benjamin Root wrote:
I just thought of a possible interaction issue that might have to be
sorted out. If we want a .set_xlim() to firmly establish the data
limits, what about a future (or previous) call to
ax.set_aspect('equal', 'datalim')? This causes the
On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
My understanding is that the proposed change will break at least some
existing code, hence my proposal to go the safer route.
On what is that understanding based? Any actual examples or use cases?
I think the only such cases would be
On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing efir...@hawaii.edu wrote:
You may well be right about this. In any case, I suspect no change will
occur prior to the 1.0 release.
I'm +1 on making the proposed change prior to mpl 1.0 (ie now). Call
to set_xlim should turn off autoscaling for the
