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