Eric Firing wrote:
> Ted Drain wrote:
>> John,
>> I think keeping the existing API is probably a good idea. What about
>> something like this:
>>
>> - Keep xlim and viewlim as they are.
>>
>> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1
>> < x2.
>>
>> - Add set_xbound(x1
; To: Eric Firing
> Cc: James Evans; John Hunter; matplotlib development list
> Subject: Re: [matplotlib-devel] API additions
>
> Sounds fine - I don't think we care too much about the "how". I
> talked w/ James and as far as we know, the aspect code is the only
> ar
Sounds fine - I don't think we care too much about the "how". I
talked w/ James and as far as we know, the aspect code is the only
area that's having a problem right now (James is going to submit a
patch to that to handle x1>x2 today).
Since we do these plots all the time, we've just seen a nu
Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about
> something like this:
>
> - Keep xlim and viewlim as they are.
>
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
>
> - Add set_xbound(x1,x2) that takes x1 then calls s
Ted Drain wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping it.
> Calling set_xlim() to invert is fine - but it never seems to stay that
> way. There is a lot of code (resizing, autoscaling, labelling, etc)
> that has a tendency to flip the axis back to it's 'u
Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about
> something like this:
>
> - Keep xlim and viewlim as they are.
>
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
>
> - Add set_xbound(x1,x2) that takes x1 then calls s
John,
I think keeping the existing API is probably a good idea. What about
something like this:
- Keep xlim and viewlim as they are.
- Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
- Add set_xbound(x1,x2) that takes x1On 10/4/07, Ted Drain <[EMAIL PROTECTED]> wrote:
On 10/4/07, Ted Drain <[EMAIL PROTECTED]> wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping
> it. Calling set_xlim() to invert is fine - but it never seems to
> stay that way. There is a lot of code (resizing, autoscaling,
> labelling, etc) that has a tendency to
John,
I think that the problem isn't doing the inversion - it's keeping
it. Calling set_xlim() to invert is fine - but it never seems to
stay that way. There is a lot of code (resizing, autoscaling,
labelling, etc) that has a tendency to flip the axis back to it's
'un-inverted' state. The id
On 10/4/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> def invert_xaxis(self, invert=True):
>
> "Invert the x-axis if 'invert' is True."
>
I like this approach over a state flag (I agree with Eric that it
would be nice to avoid if we can since it complicates communication
betwe
James,
In principle, I'm not against adding a new API for this as long as the
old one doesn't break.
I just have the usual concerns that callers of get_xlim/get_ylim don't
break because of this. The things I've tried so far seem to be working,
but all calls to get_xlim/get_ylim should be test
James,
I see that you have implemented a strategy change in axes.py for
inverted axes, with corresponding additions to the API. I don't have
strong opinions about the strategy. Keeping track of orientation via a
flag is reasonable, although I'm not positive it is better, given that
it compli
12 matches
Mail list logo
