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

[Guido van Rossum]

+1.

The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if
a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
those are also included, but the language makes it possible to interpret
this as applying only to modules that were first marked as deprecated in
3.5...

On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon <bcannon at gmail.com> wrote:

> 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.
>>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150911/d71cd3d4/attachment-0001.html>