(original) (raw)

On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcannon@gmail.com) wrote:
\>
\> 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
\>

A riff on #1, is that it gets packaged up separately and released on PyPI, this
is basically what Django did when it removed django.contrib.comments from
Django. This kind of walks a line between 1 and 2 where the module is no longer
in the standard library, but if people are actually using those things, then
they are a fairly easy \`\`pip install\`\` away. This obviously only works for
"leaf" modules that don't have other parts of the standard library depending on
them, but #1 wouldn't work fo those anyways.