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, 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
>
>
>
------------------------------------------------------------------------------
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
