Since everyone seems happy with the proposal to keep deprecated modules in
Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
4. If no one objects I will commit the change and then update formatter and
imp to say they will be removed once Python 2.7 is no longer supported.
--- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700
+++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700
@@ -2,7 +2,7 @@
Title: Deprecation of Standard Modules
Version: $Revision$
Last-Modified: $Date$
-Author: Martin von Löwis <mar...@v.loewis.de>
+Author: Brett Cannon <br...@python.org>, Martin von Löwis <
mar...@v.loewis.de>
Status: Active
Type: Process
Content-Type: text/x-rst
@@ -50,6 +50,15 @@
releases that immediately follows the deprecation; later releases may
ship without the deprecated modules.
+For modules existing in both Python 2.7 and Python 3.5
+------------------------------------------------------
+In order to facilitate writing code that works in both Python 2 & 3
+simultaneously, any module deprecated from Python 3.5 onwards that
+also exists in Python 2.7 will not be removed from the standard
+library until Python 2.7 is no longer supported. Exempted from this
+is any module in the idlelib package as well as any exceptions
+granted by the Python development team.
+
Procedure for declaring a module undeprecated
=============================================
@@ -258,12 +267,16 @@
Remove from 2.7
Documentation: None
+ Module name: imp
+ Rationale: Replaced by the importlib module.
+ Date: 2013-02-10
+ Documentation: Deprecated as of Python 3.4.
+
Module name: formatter
Rationale: Lack of use in the community, no tests to keep
code working.
- Documentation: Deprecated as of Python 3.4 by raising
- PendingDeprecationWarning. Slated for removal in
- Python 3.6.
+ Date: 2013-08-12
+ Documentation: Deprecated as of Python 3.4.
Deprecation of modules removed in Python 3.0
On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcan...@gmail.com> wrote:
> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.
>
> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the code
> only exists for transitioning purposes and you very well may have to work
> around any bugs you come across (and yes, this means changing my stance for
> the formatter module's deprecation).
>
> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is deprecated.
> It's not difficult to silence a deprecation warning and you can make it so
> that even if you use -Werror your deprecated module imports continue to
> work without throwing an exception while all other deprecations do throw an
> exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
