[matplotlib-devel] should set_xlim turn off x autoscaling?

2010-06-27 Thread Eric Firing
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


Re: [matplotlib-devel] should set_xlim turn off x autoscaling?

2010-06-27 Thread Paul Barrett
Seems like a reasonable request to me. When I use xlim to specify the
axes in a plot session, I tend to use it multiple times.  Therefore
this default behaviour would seem reasonable.

On Sun, Jun 27, 2010 at 4:40 PM, Eric Firing  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