[Python-Dev] Choosing an official stance towards module deprecation in Python 3 (original) (raw)

Berker Peksağ berker.peksag at gmail.com
Wed Sep 9 14:21:23 CEST 2015

On Tue, Sep 8, 2015 at 7:59 PM, 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.

+1

--Berker

More information about the Python-Dev mailing list