Patch for removing some unwanted, and probably not used, functions at
tkinter/__init__.

If this stuff needs to be removed it should probably go through the deprecation process.

Pushed as PendingDepricationWarnings for upcoming 3.3

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

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 :)

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.

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?

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.

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...

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.

Updated patch. Warning type is DeprecationWarning, docs mentioned that.

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.

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.

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

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.