My understanding is that the proposed change will break at least some existing code, hence my proposal to go the safer route.
Also I'm unconvinced by the justification for the change : xlim and autoscalex_on are independant attributes, why then should setting 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. 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. 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- View this message in context: http://old.nabble.com/should-set_xlim-turn-off-x-autoscaling--tp29007843p29029292.html Sent from the matplotlib - devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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
