Do we want to add a note to the CHANGELOG for this?
Ben Root
On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing efir...@hawaii.edu wrote:
On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing efir...@hawaii.edu wrote:
On Tue, 2010-06-29 at
On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:
Do we want to add a note to the CHANGELOG for this?
I did.
Eric
Ben Root
On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing efir...@hawaii.edu
wrote:
On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
Oops, sorry, that'll teach me to check more than just the last diff!
Ben
On Sat, Jul 3, 2010 at 2:11 PM, Eric Firing efir...@hawaii.edu wrote:
On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:
Do we want to add a note to the CHANGELOG for this?
I did.
Eric
Ben Root
On Wed,
On Tue, 2010-06-29 at 21:32 -0500, John Hunter wrote:
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
On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing efir...@hawaii.edu wrote:
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
On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing efir...@hawaii.edu wrote:
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
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
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
I agree, while most of the time I call set_xlim() after all plotting is
finished, there are some cases where I call it before subsequent plot calls,
and this is a little nutty. I wonder how this change in behavior would
impact basemap which always seemed to have to code around this issue?
Ben
Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).
efiring wrote:
The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
On 06/28/2010 04:42 PM, butterw wrote:
Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).
Why, specifically in this case?
I'm somewhat reluctant to see that proliferation of methods and functions.
Is there actually
On 28 June 2010 23:11, Eric Firing efir...@hawaii.edu wrote:
On 06/28/2010 04:42 PM, butterw wrote:
Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).
Why, specifically in this case?
I'm somewhat reluctant to see
Seems like a reasonable request to me. When I use xlim to specify the
axes in a plot session, I tend to use it multiple times. Therefore
this default behaviour would seem reasonable.
On Sun, Jun 27, 2010 at 4:40 PM, Eric Firing efir...@hawaii.edu wrote:
The present behavior of set_xlim and
16 matches
Mail list logo
