homepage

The PEP 387 suggests that deprecated objects or arguments are removed in version (n+1).
I've listed these DeprecationWarnings in 3.2, which are still in 3.3.
I assume that most of these deprecated objects or arguments could be removed before next release.
*_pyio*
 argument "max_buffer_size" of BufferedWriter and BufferedRWPair
*argparse*
 argument "version" and related methods of ArgumentParser
*asyncore*
 shortcut "dispatcher.*" for "dispatcher.socket.*" attributes
*base64*
 functions "encodestring" and "decodestring"
*cgi*
 functions "parse_qs" and "parse_qsl"
*configparser*
 "ParsingError.filename", "RawConfigParser.readfp", "SafeConfigParser"
*decimal*
 "Context._clamp"
*difflib*
 "SequenceMatcher.isbjunk", "SequenceMatcher.isbpopular"
*gzip*
 "GzipFile.filename"
*http.client*
 argument "strict" of HTTPResponse and HTTPConnection
*lib2to3*
 methods "set_prefix" and "get_prefix" of "pytree.Base"
*mailbox*
 argument of type "StringIO" or "text mode files"
*ntpath*
 function "splitunc"
*tarfile*
 argument "exclude" of "TarFile.add"
*trace*
 old API
*unittest*
 "assert{DictContainsSubset,RaisesRegexp,RegexpMatches}", "fail*"
*xml.etree*
 "Element.getchildren", "XMLParser.doctype"

In addition, we have some object and attributes which are triggering "PendingDeprecationWarning" in 3.2.
We may keep these warnings in 3.3, or choose to turn some of them into "DeprecationWarning", to prepare their removal in 3.5.
*cgi*
 "cgi.escape"
*distutils"
 argument compress="compress" of make_tarball
 function "check_metadata" in "command.register"
 option "force-manifest" of "command.sdist"
*importlib*
 "abc.PyLoader" and "abc.PyPycLoader"
*nntplib*
 "_NNTPBase.xgtitle" and "_NNTPBase.xpath"
*smtpd*
 the class-private "__*" attributes
*xml.etree*
 method "getiterator" of "Element" and "ElementTree"

*unittest*
 "assert{DictContainsSubset,RaisesRegexp,RegexpMatches}", "fail*"
The "fail*" should stay.
The general idea is that with Python3 we can wait a bit more before getting rid of things, because if someone jumps from 2.7 to 3.3, he might not find things that got deprecated in 3.2 and disappeared on 3.3.
That said, some of the more obscure functions/method/attributes can probably go.
Also I think that PendingDeprecations are now quite useless, since DeprecationWarnings are silenced by default. I think we can convert them to DeprecationWarnings, even if we leave them there for a couple of versions.

New changeset 221638ba5d2a by Mark Dickinson in branch 'default':
Issue #13248, issue #8540: Remove deprecated Context._clamp attribute from Decimal module.
http://hg.python.org/cpython/rev/221638ba5d2a 

I missed these warnings in C modules.
*array*
 "fromstring" and "tostring" methods
*io* (like _pyio)
 argument "max_buffer_size" of BufferedWriter and BufferedRWPair
*sys*
 "sys.getcheckinterval" and "sys.setcheckinterval"
and some complaints from Objects/typeobject.c:
 "object.__init__() takes no parameters"
 "object.__new__() takes no parameters"
 "object.__format__ with a non-empty format string is deprecated"
 "Type %.100s defines tp_reserved (formerly tp_compare) but not "
 "tp_richcompare. Comparisons may not behave as intended."

> *array*
> "fromstring" and "tostring" methods
I think these ones (and other well-known 2.x methods) should be kept to ease porting to 3.x.

Maybe a 2to3 fixer to convert the names should be added?

distutils will not change. I’ll ask if removing the deprecation warnings is okay, otherwise they’ll stay.
For ConfigParser.readfp, it would ease porting between 2.x and 3.x if the method could stay longer, or forever.

The difflib deprecations are mine and I think they should happen in 3.3.
This will serve as a reminder.

New changeset f82ebf9b3a52 by Florent Xicluna in branch 'default':
Issue #13248: turn 3.2's PendingDeprecationWarning into 3.3's DeprecationWarning (cgi, importlib, nntplib, smtpd).
http://hg.python.org/cpython/rev/f82ebf9b3a52 

I know it won't be committed as-is, but this is the patch with most of the deprecated things removed.
I skipped all the modules where a veto has been pronounced explicitly.

.. versionchanged:: 3.2
- The *strict* parameter is deprecated. HTTP 0.9-style "Simple Responses"
+ The *strict* parameter is removed. HTTP 0.9-style "Simple Responses"
 are not supported anymore.
Such change looks wrong: the parameter exists in Python 3.2.

I think most of these shouldn't be removed, as it would make porting from 2.x significantly more tedious.
Things that I think can be removed:
- max_buffer_size (io is new and that argument was never used by anybody)
- get_prefix / set_prefix (the internal lib2to3 API is not documented AFAICT)
- the argparse things (argparse is new)

I removed object.__format__ from the patch because it is not planned for removal in 3.3, but in 3.4 (see issue #9856).
I've fixed the documentation *versionchanged* and split the patch in two.
The first is less controversial.
The second might be delayed a little to ease the migration from 2.x to 3.x.

Given the discussions we’ve had this month and a few months earlier about people porting directly to 3.2 or 3.3, I think the second patch needs to wait for 3.4 or 3.5. (I have no opinion on the first patch, not being a customer of lib2to3 or pyio.)

I think it would be better to decide in what version each thing will be removed and then mark them with the deprecated-removed directive in the doc.

In unittest, DictContainsSubset() should be removed from 3.3. It was defective by design (wrong argument order). I concur with Ezio that the other unittest methods should remain intact. I'm not sure whether assertSameElements() should stay or go (when Google's code search was still up, it showed zero uptake for that test method, so it may be better to remove it now).
The Decimal module's Context._clamp should also be removed from 3.3. It was a private API from the outset and won't be mirrored in the C version. It looks like Mark has already done this one.
I also agree Antoine that most of the other changes shouldn't be made in 3.3 except for the three he listed: max_buffer_size, get_prefix/set_prefix, and the argparse deprecations.

New changeset b30171bbc571 by Benjamin Peterson in branch 'default':
remove get_prefix and set_prefix (#13248)
http://hg.python.org/cpython/rev/b30171bbc571 

New changeset 0ddb78341290 by Raymond Hettinger in branch 'default':
Issue #13248: Removed docs for two deprecated unittest features. To be conservative, the code is left in for one more release.
http://hg.python.org/cpython/rev/0ddb78341290 

Raymond, I think it's better to leave the documentation and use "deprecated-removed" to signal clearly that those functions are deprecated and when they will be removed (even if this means 3.4).
IME removing documentation creates more confusion because people that find those functions in some codebase will have an hard time figuring out what they are, where do they come from, if they are deprecated or not and when they will be removed.

Ezio, I'm was thinking of marking the code and its docstring as removed/unused, but if you want the code removed altogether, that would be fine.

I don't mind if they are removed in 3.3 or 3.4, as long as they are documented in all the versions where they are present.

Do we agree to remove the "max_buffer_size" from the "io" module in 3.3?
This argument is unused, and deprecated. Just dead code.
See attachment.

> Do we agree to remove the "max_buffer_size" from the "io" module in 3.3?
Yes!

New changeset 5393382c1b1d by Florent Xicluna in branch 'default':
Issue #13248: argparse: Remove obsolete argument "version" of ArgumentParser.
http://hg.python.org/cpython/rev/5393382c1b1d
New changeset 700f989afbad by Florent Xicluna in branch 'default':
Issue #13248: io: Remove obsolete argument "max_buffer_size" of BufferedWriter and BufferedRWPair.
http://hg.python.org/cpython/rev/700f989afbad 

Flox, could you put versionchanged (or versiondeprecated-removed, which could also go into 3.2) to note the removals in the doc?

Eric, I will check but I thought they were not documented.

We do not document removals after they are done as they are not an issue for back-compatibility (unlike changes and additions).
Deprecation Warnings are optionally available for checking forward-compatibility. Deprecations are sometimes noted in the regular text flow with things like "encodestring is a deprecated alias", but they are not set off with separate versionchanged: notices, as nothing has changed yet. Some deprecated features are not even documented.
The 'version' arg of class ArgumentParser is already not documented in 3.2, which is why the patch does not change argparse.rst.
"A third argument, max_buffer_size, is supported, but unused and deprecated." and "A fourth argument, max_buffer_size, is supported, but unused and deprecated." is enough for that parameter (and the patch removes those lines -- the param was already left out of the signature).

The other changes are in the patch "issue13248_obsolescence_v3.diff".
AFAIU, they will not be removed in 3.3, in order to facilitate transition from Python 2.
*asyncore*
 shortcut "dispatcher.*" for "dispatcher.socket.*" attributes
*base64*
 functions "encodestring" and "decodestring"
*cgi*
 functions "parse_qs" and "parse_qsl"
*gzip*
 "GzipFile.filename"
*http.client*
 argument "strict" of HTTPResponse and HTTPConnection
*mailbox*
 argument of type "StringIO" or "text mode files"
*ntpath*
 function "splitunc"
*tarfile*
 argument "exclude" of "TarFile.add"
*trace*
 old API

New changeset 612d8bbcfa3a by Terry Jan Reedy in branch 'default':
Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.
http://hg.python.org/cpython/rev/612d8bbcfa3a 

New changeset 62a988b3bf2e by Terry Jan Reedy in branch 'default':
Issue #13248: NEWS and What's New items
http://hg.python.org/cpython/rev/62a988b3bf2e 

> We do not document removals after they are done as they are not an
> issue for back-compatibility (unlike changes and additions).
I learned that people may use the (for example) 2.7 docs even though they are using 2.6, so I think we do want to use things like the deprecated-removed directive to tell these users that they should start looking for a replacement. Removing documentation would lead them to look in other places and discover the removals later.

IMHO deprecated-removed should be used on versions where the feature exists, and a versionchanged should be added once the feature has been removed.

The attached patch removes assertDictContainsSubset().

Apparently we missed some of the stuff here.

New changeset 2cceb8cb552b by Giampaolo Rodola' in branch 'default':
fix isuse #13248: remove previously deprecated asyncore.dispatcher __getattr__ cheap inheritance hack.
http://hg.python.org/cpython/rev/2cceb8cb552b 

Anything else left to do on this?

Can this be closed as plenty of changesets have been pushed?

At most half of the items listed in the original post have been dealt with. Each remaining 'deprecated items should be removed in 3.5, undeprecated, or a decision recorded to leave it deprecated indefinitely.

See Issue 19167 for a patch to remove the xml.etree.XMLParser.doctype() method. I’m happy for it to be removed, since the logic for generating the DeprecationWarning is buggy.

Make that Issue 19176 for XMLParser.doctype()

Another one to deal with one way or the other: html.parser.HTMLParser.unescape()
It is apparently due to be removed in 3.5. It was meant to be an undocumented internal function, and there is now an public alternative. However I would be inclined to leave it around a little longer, because it seems to have been widely recommended for decoding HTML entities in the past (e.g. <https://wiki.python.org/moin/EscapingHtml>), and keeping it would simplify maintaining Python 2 compatible code.

Here is a follow-up list:
* formatter module (will be removed in Python 3.6)
* asynchat.fifo() (will be removed in Python 3.6)
* buffering argument of bz2.BZ2File() (deprecated in 2011)
* tarfile.filemode() (deprecated in 2012)
* SO config var (sysconfig.get_config_var()) (deprecated in 2013)
* platform.popen() (deprecated in 2011)
* ntpath.splitunc() (deprecated in 2009)
* inspect.getmoduleinfo() (deprecated in 2012)

New changeset a565aad5d6e1 by Yury Selivanov in branch 'default':
Issue #13248: Remove inspect.getargspec from 3.6 (deprecated from 3.0)
https://hg.python.org/cpython/rev/a565aad5d6e1 

New changeset 558199e060fd by Yury Selivanov in branch 'default':
Issue #13248: Remove inspect.getmoduleinfo() from 3.6 (deprecated in 3.3)
https://hg.python.org/cpython/rev/558199e060fd 

the function getargspec was removed but references to it within docstrings remained:
$> git grep getargspec
Doc/library/inspect.rst: The first four items in the tuple correspond to :func:`getargspec`.
Doc/library/inspect.rst: :func:`getargspec` or :func:`getfullargspec`.
Doc/whatsnew/3.4.rst::func:`~inspect.getfullargspec` and :func:`~inspect.getargspec`
Doc/whatsnew/3.5.rst:* :func:`inspect.getargspec` is deprecated and scheduled to be removed in
Doc/whatsnew/3.6.rst:* ``inspect.getargspec()`` was removed (was deprecated since CPython 3.0).
Lib/inspect.py: getargspec(), getargvalues(), getcallargs() - get info about function arguments
Lib/inspect.py: The first four items in the tuple correspond to getargspec().
Lib/inspect.py: """Format an argument spec from the values returned by getargspec
Lib/test/test_inspect.py:# getclasstree, getargspec, getargvalues, formatargspec, formatargvalues,
Misc/NEWS:- Issue #13248: Remove deprecated inspect.getargspec and inspect.getmoduleinfo

New changeset ad4c1bfe257f by Berker Peksag in branch 'default':
Issue #13248: Delete remaining references of inspect.getargspec().
https://hg.python.org/cpython/rev/ad4c1bfe257f 

Thank you, Berker!

Did you keep this ticket open for a reason?