On 14/08/2013 17:17, Eli Bendersky wrote:



On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@gmail.com>> wrote:

    On 14 August 2013 11:55, Brett Cannon <br...@python.org
    <mailto:br...@python.org>> wrote:
     > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan
    <ncogh...@gmail.com <mailto:ncogh...@gmail.com>> wrote:
     >>
     >> On 14 August 2013 11:08, Brett Cannon <br...@python.org
    <mailto:br...@python.org>> wrote:
     >> > We take adding a module to the stdlib very seriously for all
    of these
     >> > reasons and yet people seem to forget that the exact same
    reasons apply
     >> > to
     >> > modules already in the stdlib, whether they would be added
    today or not
     >> > (and
     >> > in this instance I would argue not). There is a balance to
    keeping the
     >> > load
     >> > of work for core devs at a level that is tenable to the level
    of quality
     >> > we
     >> > expect from ourselves which means making sure we don't let
    cruft build
     >> > up in
     >> > the stdlib and overwhelm us.
     >>
     >> I've already suggested a solution to that at the language summit
    [1]:
     >> we create a "Legacy Modules" section in the docs index and dump all
     >> the modules that are in the "These are only in the standard library
     >> because they were added before PyPI existed, aren't really actively
     >> maintained, but we can't remove them due to backwards compatibility
     >> concerns" category there.
     >>
     >> Clear indication of their status for authors, educators, future
    users
     >> and us, with no risk of breaking currently working code.
     >
     >
     > 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.


+1 for both and for leaving the module in until "Python 4".

Nick, perhaps we can have this "legacy-zation" process for modules
documented somewhere? Devguide? mini-PEP?

What about also for certain features of modules, such as re's LOCALE
flag?

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to