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