From: Eric F. <ef...@ha...> - 2010-06-30 01:52:49
|
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. > > 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. > > 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. Eric > > > efiring 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 that proliferation of methods and functions. > > > > Is there actually a reasonable use case for the present behavior--is it > > advantageous under some circumstances? What sort of code is likely to > > depend on it? > > > > Eric > > > >> > >> > >> > >> 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 > >>> requires manually calling set_autoscalex_on(False) etc. It would seem > >>> more logical if set_xlim itself included the call to turn autoscalex > >>> off--isn't that what a user would almost always want and expect? > >>> > >>> Rectifying this would constitute a significant change affecting some > >>> existing user code. > >>> > >>> What are people's thoughts on this? Should the change made? If so, do > >>> it abruptly, right now, as part of version 1.0? Or phase it in with a > >>> temporary kwarg and/or rcparam? It would be nice to avoid all that > >>> complexity, but may be we can't, except by leaving everything as it is > >>> now. > >>> > >>> 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 > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > |