On Wed, Aug 14, 2013 at 11:37 AM, Terry Reedy <tjreedy at udel.edu> wrote: > On 8/14/2013 12:09 PM, Nick Coghlan wrote: > >> On 14 August 2013 11:55, Brett Cannon <brett at python.org> wrote: >> > > 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. >> > > 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. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130814/289350d6/attachment.html>
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