OK to delete methods?

#1

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

delete_tick_methods.diff (2.61 KB)

#2

Hi Eric,

In general I'm all for it - simplicity is good. Just make sure that it doesn't break the spine placement code (e.g. examples/pylab_demo/spine_placement_demo.py ) -- I remember those method names from the time when I was working on the spines. I don't remember any deep issues, but it's long enough ago now that I don't remember the details.

Thanks,
Andrew

···

On 8/21/10 12: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.

#3

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

#4

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

···

On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing <efiring@...229...> 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.

#5

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

···

On 08/23/2010 05:17 AM, John Hunter wrote:

On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing<efiring@...229...> wrote:

------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel