[Python-Dev] Deprecating the formatter module

[MRAB]

On 14/08/2013 17:17, Eli Bendersky wrote:
>
>
>
> On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
>
>     On 14 August 2013 11:55, Brett Cannon <brett at python.org
>     <mailto:brett at python.org>> wrote:
>      > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan
>     <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
>      >>
>      >> On 14 August 2013 11:08, Brett Cannon <brett at python.org
>     <mailto:brett at 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?