matplotlib-devel Mailing List for matplotlib

On 08/23/2010 05:17 AM, John Hunter wrote:
> On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing<ef...@ha...> wrote:
>> Mike, John, or anyone else who works directly with Ticks:
>>
>> I think you are the only ones who have worked with the code I suggest
>> changing as in the attached diff. It looks to me like the three *Tick
>> methods, set_view_interval(), get_minpos(), get_data_interval(), are unused
>> and unlikely ever to have been or to be used. I particularly object to the
>> first of these because I don't think a Tick has any business changing the
>> view interval. The other two look like clutter, harmless except insofar as
>> they make it harder to understand the code. If some projection actually does
>> end up needing the functionality in any of these methods, it is still
>> available via *Tick.axes.xaxis.* etc.
>>
>> Am I missing something? If not, I will commit this to the trunk. This is a
>> case where I think immediate surgery is better than a deprecation process.
>
> I'm OK with removing them, and I don't feel strongly about deprecation
> with a helpful suggestion or radical mastectomy, though the former
> seems a little gentler. This should go into the trunk only since it
> is API breaking.
>
> JDH
Committed to the trunk in r8655. I agree that deprecation is gentler, 
and that is the route I usually take; but given the obscurity of the 
Tick classes and the oddness of these methods in that class, I'm taking 
a chance on just getting it over with now. Time will tell whether it is 
a mistake. If it is, it won't be the first or the last.
Eric
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing <ef...@ha...> wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest
> changing as in the attached diff. It looks to me like the three *Tick
> methods, set_view_interval(), get_minpos(), get_data_interval(), are unused
> and unlikely ever to have been or to be used. I particularly object to the
> first of these because I don't think a Tick has any business changing the
> view interval. The other two look like clutter, harmless except insofar as
> they make it harder to understand the code. If some projection actually does
> end up needing the functionality in any of these methods, it is still
> available via *Tick.axes.xaxis.* etc.
>
> Am I missing something? If not, I will commit this to the trunk. This is a
> case where I think immediate surgery is better than a deprecation process.
I'm OK with removing them, and I don't feel strongly about deprecation
with a helpful suggestion or radical mastectomy, though the former
seems a little gentler. This should go into the trunk only since it
is API breaking.
JDH

I think you're right about this.
Mike
On 08/21/2010 03:08 PM, Eric Firing wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest 
> changing as in the attached diff. It looks to me like the three *Tick 
> methods, set_view_interval(), get_minpos(), get_data_interval(), are 
> unused and unlikely ever to have been or to be used. I particularly 
> object to the first of these because I don't think a Tick has any 
> business changing the view interval. The other two look like clutter, 
> harmless except insofar as they make it harder to understand the code. 
> If some projection actually does end up needing the functionality in 
> any of these methods, it is still available via *Tick.axes.xaxis.* etc.
>
> Am I missing something? If not, I will commit this to the trunk. 
> This is a case where I think immediate surgery is better than a 
> deprecation process.
>
> Thanks.
>
> Eric
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA