-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecated in 3.2/3.3, should be removed in 3.5 or ??? #57457
Comments
The PEP-387 suggests that deprecated objects or arguments are removed in version (n+1). *_pyio* |
In addition, we have some object and attributes which are triggering "PendingDeprecationWarning" in 3.2. *cgi* |
*unittest* 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': |
I missed these warnings in C modules. *array* and some complaints from Objects/typeobject.c: "object.__init__() takes no parameters" |
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. |
New changeset f82ebf9b3a52 by Florent Xicluna in branch 'default': |
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:
|
I removed object.__format__ from the patch because it is not planned for removal in 3.3, but in 3.4 (see issue bpo-9856). I've fixed the documentation *versionchanged* and split the patch in two. |
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': |
New changeset 0ddb78341290 by Raymond Hettinger in branch 'default': |
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. |
Yes! |
New changeset 5393382c1b1d by Florent Xicluna in branch 'default': New changeset 700f989afbad by Florent Xicluna in branch 'default': |
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". *asyncore* *base64* *cgi* *gzip* *http.client* *mailbox* *ntpath* *tarfile* *trace* |
New changeset 612d8bbcfa3a by Terry Jan Reedy in branch 'default': |
New changeset 62a988b3bf2e by Terry Jan Reedy in branch 'default': |
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': |
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 bpo-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 bpo-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:
|
New changeset a565aad5d6e1 by Yury Selivanov in branch 'default': |
New changeset 558199e060fd by Yury Selivanov in branch 'default': |
the function getargspec was removed but references to it within docstrings remained: $> git grep getargspec |
New changeset ad4c1bfe257f by Berker Peksag in branch 'default': |
Thank you, Berker! |
Did you keep this ticket open for a reason? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: