classification
Title: Removing apparently unwanted functions from Tkinter
Type: behavior Stage: patch review
Components: Tkinter Versions: Python 3.4, Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: asvetlov Nosy List: asvetlov, brian.curtin, gpolo, python-dev, r.david.murray, rhettinger, terry.reedy
Priority: low Keywords: needs review, patch

Created on 2008-06-03 18:32 by gpolo, last changed 2012-03-31 12:01 by asvetlov. This issue is now closed.

Files
File name Uploaded Description Edit
removed_index_funcs.diff gpolo, 2008-06-03 18:32 review
issue3035.diff asvetlov, 2012-03-29 18:42 review
issue3035.diff asvetlov, 2012-03-29 20:04 review
Messages (15)
msg67669 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-06-03 18:32
Patch for removing some unwanted, and probably not used, functions at
tkinter/__init__.
msg97750 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-01-14 02:56
If this stuff needs to be removed it should probably go through the deprecation process.
msg156518 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-03-21 21:48
Pushed as PendingDepricationWarnings for upcoming 3.3
msg156519 - (view) Author: Roundup Robot (python-dev) Date: 2012-03-21 21:53
New changeset d42f264f291e by Andrew Svetlov in branch 'default':
Issue #3035: Unused functions from tkinter are marked as pending peprecated.
http://hg.python.org/cpython/rev/d42f264f291e
msg156520 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-21 21:53
PendingDeprecationWarning would mean that we are going to remove it "someday".  If you actually want to remove them in a reasonable time, you should use "DeprecationWarning" in 3.3, and then remove them in 3.4.

But is there a need to remove them?  Maybe PendingDeprecationWarning is right and we'll remove them in Python4 :)
msg156521 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-21 21:55
Also, posting a patch for review before committing is a good idea.  If you don't get a review in a reasonable time period, then as a committer you can of course go ahead and commit, based on your judgement.
msg156535 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-03-22 01:48
I do not know or directly use tkinter enough to judge the proposed removal. (Although they do look like they might be useless.) I would like to see a little more explanation on the record. Who wrote
"# XXX I don't like these -- take them away"?

Also, deprecation messages often give the alternative or replacement to what is being removed. Are these so useless that there is no replacement?
msg156615 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-03-22 20:27
David Murray,
I used to think what deprecation process in Python have to go trough PendingDeprectaionWarning to DeprecationWarning and removing in next next release at end. Is it right?
Also I thought what that trivial patch does not need to be published in tracker. Will do next time.

Terry J. Reedy, the message what you asked was made by GvR in 1995.
That functions can be used to point position in text widget (single-line Entry doesn't support it).

Now I think we need to deprecate that functions, but also add keyword-only parameters in widgets methods which can accept that ones.
Documentation need to be updated as well.

I'll make a patch for that.

Thank you for mentoring.
msg156620 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-22 21:10
You are theoretically right about not posting trivial patches, but as you can see, sometimes even a trivial patch elicits unexpected insights.  So I like to always post my patches, even the seemingly trivial ones.  Then if I don't get any responses, I figure it is OK to to ahead on the trivial ones :)

Of course, I don't do this 100% of the time.  This is especially true if there has been prior discussion, or sometimes discussion on IRC (although in the latter case I still may post the patch and always post summary of the IRC discussion).

As for the deprecation process. PendingDeprecationWarning was introduced for...I forget which feature it was.  Something that was going to be around for several releases, anyway.  And I think that feature wound up not getting removed until Python3, but I don't remember for sure.

Then for a short time we did start using it as you say, giving a three release deprecation cycle (pending, deprecated, gone), but that was before deprecation warnings were made silent.  PendingDeprecations were silent, you see, so using them one release early was a hack around the fact that DeprecationWarnings were *not* silent.

On the other hand I think we've gotten more strict about "needless" deprecations.  If there's no harm in leaving something in, we leave it in.  It's too bad Guido's comment wasn't noticed at the Python3 boundary; that is the perfect time to remove such cruft.  So doing a PendingDeprecationWarning to remind ourselves that this is something we want to remove in Python4 is also a reasonable approach.  Really, I think this is an area where our procedures and criteria are still a bit in flux...
msg156672 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2012-03-23 19:16
Usually, I would counsel against removing anything that isn't broken by design, but the code for these functions offers nothing substantive.  So, +1 for marking as deprecated in 3.3 and removing in 3.4.
msg157082 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-03-29 18:42
Updated patch. Warning type is DeprecationWarning, docs mentioned that.
msg157089 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-03-29 19:19
Raymond is suggesting removal in 3.4, and given that we are doing it I don't see any reason to wait for 3.5, either, so you probably want to update the warning messages to say 3.4 instead of 3.5.  Otherwise it looks good to me.

Ezio suggested adding a test that fails if we don't do the deprecation in 3.4 (that is, when the feature release number changes, the test starts failing).  And/or you can open a new 3.4-only issue "remove deprecated tkinter functions" and mark it as a release blocker.
msg157092 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-03-29 20:04
Thank you, David.

I've updated the patch.

I think making new test for check is easy but Issue14446 is good enough.
Running stupid test doesn't make sense for this case.
msg157175 - (view) Author: Roundup Robot (python-dev) Date: 2012-03-31 11:57
New changeset 2bc374182ed4 by Andrew Svetlov in branch 'default':
issue #3035: update PendingDeprecationWarning to DeprectionWarning, point deprecation in tkinter doc
http://hg.python.org/cpython/rev/2bc374182ed4
msg157178 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-03-31 12:01
I've updated the patch following David's recommendations, pushed it into default branch.

#14446 has been made to remove deprecated code in 3.4

Closing the issue as fixed.
History
Date User Action Args
2012-03-31 12:01:49asvetlovsetstatus: open -> closed
resolution: remind -> fixed
messages: + msg157178
2012-03-31 11:57:27python-devsetmessages: + msg157175
2012-03-29 20:04:34asvetlovsetfiles: + issue3035.diff

messages: + msg157092
2012-03-29 19:19:21r.david.murraysetmessages: + msg157089
2012-03-29 18:44:25asvetlovsetstage: patch review
2012-03-29 18:42:57asvetlovsetfiles: + issue3035.diff

messages: + msg157082
2012-03-23 19:16:17rhettingersetnosy: + rhettinger
messages: + msg156672
2012-03-22 21:10:58r.david.murraysetmessages: + msg156620
2012-03-22 20:27:46asvetlovsetmessages: + msg156615
2012-03-22 01:48:42terry.reedysetnosy: + terry.reedy
messages: + msg156535
2012-03-21 21:55:58r.david.murraysetmessages: + msg156521
2012-03-21 21:53:57r.david.murraysetnosy: + r.david.murray
messages: + msg156520
2012-03-21 21:53:12python-devsetnosy: + python-dev
messages: + msg156519
2012-03-21 21:48:01asvetlovsetversions: + Python 3.3, Python 3.4, - Python 3.2
messages: + msg156518

assignee: asvetlov
resolution: remind
stage: patch review -> (no value)
2012-03-21 17:23:56asvetlovsetnosy: + asvetlov
2010-01-14 02:56:45brian.curtinsetpriority: low

type: behavior
versions: + Python 3.2, - Python 3.0
keywords: + needs review
nosy: + brian.curtin

messages: + msg97750
stage: patch review
2008-06-03 18:32:48gpolocreate