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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4