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
