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

Brett Cannon bcannon at gmail.com
Tue Sep 8 19:29:47 CEST 2015

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>

More information about the Python-Dev mailing list