(original) (raw)
On Wed, Aug 14, 2013 at 11:37 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 8/14/2013 12:09 PM, Nick Coghlan wrote:
On 14 August 2013 11:55, Brett Cannon <brett@python.org> wrote:
At least a couple of releases before deletion, we should put a 'legacy' package up on pypi. Then the deprecation message could say to use that as an alternative.I view a deprecation as the same thing. If we leave the module in until
Python 4 then I can live with that, but simply moving documentation around
is not enough to communicate to those who didn't read the release notes to
know modules they rely on are now essentially orphaned.
No, a deprecation isn't enough, because it doesn't help authors and
educators to know "this is legacy, you can skip it". We need both.
To reiterate a point that was raised previously -- IMHO it would be a mistake to actually delete this (or other) modules before "Python 4". There's been enough breakage in Python 3 already. Some projects may only switch to Python 3.x when x is 4 or 5 or 9\. Let's not make it even harder! I suggest we revisit this issue when the module in question becomes an actual maintenance burden. For the time being, if we feel bad this module isn't well documented/tested/understood, ISTM that moving it to "deprecated" status and to a "legacy/obsolete" section of the library documentation should help us handle those feelings of guilt.
Eli