[Python-Dev] Deprecating the formatter module

[Nick Coghlan]

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia