On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano <st...@pearwood.info>wrote:
> On 13/08/13 23:36, Brett Cannon wrote: > >> On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka <storch...@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.
_______________________________________________ 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
