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 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 interactive scripts. One can
> > > imagine a script in which a plot is made, the user views it, perhaps
> > > uses a gui to change the limits, then presses a button to plot the next
> > > data set on top of the first, expecting that it will again autoscale,
> > > and so forth. Maybe this is sufficient justification for leaving the
> > > present version alone. That is what I am trying to find out. In
> > > addition, the change would require scanning the internal mpl code to
> see
> > > whether there are uses of set_xlim that would have to be changed.
> >
> > The points you make are exactly what I was thinking about.
> > A subtle alteration of the behaviour of matplotlib caused by the
> > change is the worse case scenario, because it might not be
> > straightforward to detect/correct.
> > I also have a number of matplotlib interactive scripts /GUIs used in
> > production. Most rely on precise control of the viewing area and some
> > will be affected by the change.
> >
> > >
> > >>
> > >> Also I'm unconvinced by the justification for the change :
> > >> xlim and autoscalex_on are independant attributes, why then should
> setting
> > >
> > > They are not independent, they are potentially in conflict--two
> > > mechanisms fighting for control of the axis.
> > >
> > >> xlim have the side effect of turning autoscalex off ? This is not
> consistent
> > >> with how the API works. If I really wanted autoscalex off, I would
> have
> > >> specified it.
> > >
> > > The idea of having interactive plotting commands is to make the
> > > interaction easy and natural. When you call set_xlim interactively, it
> > > is because that is what you want the limits to be. At least that point
> > > of view has been expressed several times on the lists. I have yet to
> > > hear someone say, "I rely on the present behavior". In scripts, when
> > > there is no interactive scenario such as I described in the previous
> > > paragraph, the problem with the present behavior is that it means
> > > set_xlim has no effect at all if followed by a plot command unless one
> > > has disabled autoscaling either via a kwarg in the plot command, or via
> > > ax.set_autoscalex_on(False). The latter is just plain ugly, to my eye.
> >
> > My personal opinion is that the current behaviour is not broken.
> > When typing commands interactively in pylab or writing a regular
> > script it can be frustrating. But in interactive GUIs it is useful to
> > have full independent control over the two parameters.
> > In most cases I agree that the proposed behaviour is what the user
> > wants. But this is not true in all cases.
> >
> > >> To sum things up:
> > >> Adding an argument to set_xlim to allow autoscale to be turned off in
> the
> > >> same step would be a good idea. But it shouldn't suddenly become the
> default
> > >> behaviour.
> > >
> > > You may well be right about this. In any case, I suspect no change
> will
> > > occur prior to the 1.0 release.
> > >
> > > Additional perspective: the behavior of Matlab's xlim is as I have
> > > proposed, not as mpl xlim presently works. I don't believe in
> following
> > > Matlab slavishly--sometimes we can make better choices than Matlab
> > > has--but I think that this is a case where Matlab got it right and we
> > > did not, the first time around. This may be because the _autoscalex
> and
> > > _autoscaley attributes were added to the mpl Axes long after set_xlim.
> >
> > As the change of default behaviour seems to be going ahead, I must
> > request the addition of an new argument to xlim (autoscalex=False).
> > The purpose being to allow the user to modify his code to retain the
> > current behaviour when desired.
>
> I made two commits, 8479 and 8480. Other developers are welcome to
> revert them or modify them as needed. Certainly they need testing and
> review, the more, the better. I had to change quite a few things, so
> there is risk, as you note. I am a bit concerned about whether enough
> people will be able to do enough testing of this before release to shake
> out any bugs.
>
> The new kwarg for set_xlim and set_ylim is simply "auto"; set it to None
> to obtain the old behavior:
>
> *auto*: [ True | False | None ]
> turn *x* autoscaling on (True), off (False; default),
> or leave unchanged (None)
>
> set_xbound retains the old behavior, by calling set_xlim with auto=None.
>
> We have several options at present. If the changes I made are junk,
> they can be discarded, or deferred until more time is available for
> testing and reworking. If they are basically sound but too abrupt, then
> the default could be changed to auto=None, with the possibility of
> shifting it later. Additionally, an rcparam could be used, although I
> don't like making ever more rcparams.
>
> In addition to the changes to set_xlim, I tried to clarify the
> documentation, and I added an "autoscale" convenience method and pyplot
> function, which I think was needed.
>
> One more change I would like to see is the simple and, I think, safe one
> of supporting descriptive kwarg names alongside the present misleading
> ones: e.g. for xlim, "left" would be equivalent to "xmin", etc.
>
>
> I am on a ship until July 5, working with a high-latency internet
> connection through an intermediate machine, and I can't afford much more
> time on this while I am out here. (And working with svn from here is
> pretty cumbersome.)
>
> Eric
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
