I just thought of a possible interaction issue that might have to be sorted
out. If we want a .set_xlim() to firmly establish the data limits, what
about a future (or previous) call to ax.set_aspect('equal', 'datalim')?
This causes the data limits to change within the figure box.
Ben Root
On Mon, Jun 28, 2010 at 10:48 PM, Anne Archibald <aarch...@physics.mcgill.ca
> wrote:
> 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
>
------------------------------------------------------------------------------
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
