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. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
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