On 28 June 2010 23:11, Eric Firing <efir...@hawaii.edu> 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?
The present behaviour bites me every time. I keep forgetting that the xlim has to be last and plotting afterward. So I'd prefer this change. But let me be the devil's advocate. Suppose I want to plot a number of different things, with autoscaling so that the plot fits them all. This won't change. Now suppose I want the "autoscaling" to actually include, for each plotting action, explicitly set x and y limits. This still won't change. But if I want to omit some of the x and y limits, then the behaviour might change. That is, if I have some framework designed to plot several things in a row on the same plot, and if that framework sometimes calls xlim/ylim when new things are added, but not always, then I might find this change an unpleasant surprise. I'd be inclined to handle this with a warning - if possible, one that was triggered only when drawing something that would have triggered a rescaling but now no longer does. If that's infeasible, my inclination would be to just change it. But I won't be the one who's stuck dealing with a stream of puzzled users... Anne > 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 > ------------------------------------------------------------------------------ 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
