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

[Brett Cannon]

On Tue, 8 Sep 2015 at 10:08 Donald Stufft <donald at stufft.io> wrote:

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

That is one possibility, but I notice that django.contrib.comments is still
getting updated. For deprecated modules they probably won't even get
bugfixes anymore so I wouldn't want to give the wrong impression the
modules are still being maintained. Plus we would have to figure out who is
in charge of the actual project on PyPI since there isn't a concept of
group ownership.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/387006dd/attachment.html>