[Python-Dev] Deprecating the formatter module

Brett Cannon brett at python.org
Wed Aug 14 17:08:29 CEST 2013

On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano <steve at pearwood.info>wrote:

> On 13/08/13 23:36, Brett Cannon wrote:
>> On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka <storchaka at gmail.com
>> >wrote:
>>  12.08.13 22:22, Brett Cannon написав(ла):
>>>   I have created http://bugs.python.org/****issue18716<http://bugs.python.org/**issue18716>
>>> <http://bugs.python.**org/issue18716 <http://bugs.python.org/issue18716>>to
>>> deprecate the
>>>  formatter module for removal in Python 3.6 unless someone convinces me
>>>> otherwise that deprecation and removal is the wrong move.
>>> The formatter module doesn't look such buggy as the audioop module. If
>>> the
>>> formatter module was not removed in Python 3.0 I don't see why it can't
>>> wait to 4.0.
>> It doesn't help that at PyCon CA we couldn't find a single person who had
>> heard of the module (which included people like Alex Gaynor and Larry
>> Hastings).
> You know, there may be one or two Python programmers who didn't go to
> PyCon CA... :-)

Sure, but you would assume at least *one* person would have known of the
module in a room of sprinters.

> I knew of formatter before this thread. I've looked at it for use in my
> own code, but the lack of useful documentation or clear examples put me
> off, so I put it in the pile of "things to investigate later", but it is
> definitely a module that interests me.

Sure, but not to the extent to try and update the documentation, provide
examples, etc. And totally lacking tests doesn't help with the argument
there is interest in it either.

> The documentation for 2.7 claims that it is used by HTMLParser, but that
> doesn't appear to be true. The claim is removed from the 3.3 documentation.
> Over on Python-Ideas mailing list, there are periodic frenzies of requests
> to delete all sorts of things, e.g. a recent thread debating deleting
> various string methods in favour of using {} string formatting. My answer
> there is the same as my answer here: unless the formatter module is
> actively harmful, then deprecation risks causing more pain than benefit.
> All those thousands of coders who don't use formatter? The benefit to them
> of deprecating it is next to zero. That one guy in Uberwald you've never
> heard of who does use it? It's going to cause him a lot of pain.

That's fine, but this is also about me and every other core developer who
stands behind every module in the stdlib as being as bug-free as possible
and generally useful to warrant people learning about them. I'm saying I
don't want to maintain it and have to clean up it's code every time there
is a stdlib-wide cleanup or if there is ever a bug. Every bug takes time
and effort away -- no matter how infrequently the module has them -- from
other modules which people could be focusing their time on which have a
greater impact on the wider community. You can argue that some core dev
might care enough to maintain it, but unless someone lists themselves on
http://docs.python.org/devguide/experts.html for a module then the burden
of maintenance falls on all of us.

There is also the issue of semantic overload in terms of simply trying to
keep straight what is in the stdlib. It also means book authors need to
decide whether to care about this module or not and use it in examples.
Teachers need to be aware of the module to answer questions, etc.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130814/2bf21f4c/attachment.html>

More information about the Python-Dev mailing list