[Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

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 <martin at v.loewis.de>
+Author: Brett Cannon <brett at python.org>, Martin von Löwis <
martin at 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 <bcannon at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/8d698c37/attachment.html>