[Python-Dev] PEP 594: update 1 (original) (raw)
Steven D'Aprano steve at pearwood.info
Thu May 23 20:44:22 EDT 2019
- Previous message (by thread): [Python-Dev] PEP 594: update 1
- Next message (by thread): [Python-Dev] PEP 594: update 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote:
On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch <_ _sean.wallitsch at dreamworks.com> wrote:
> My apologies for that oversight. My understanding is that many of the > methods present in aifc depend heavily on audioop for reading and writing. > But are people using audioop directly?
Yes they are.
Shouldn't the PEP be responsable for establishing (as well as any negative can be proven) that these modules aren't used, rather than merely assuming that they aren't?
Of course it is hard to establish that a module isn't being used. Not all code can be searched for on the Internet, there's huge amounts of non-open source code written by users that never leaves their computer, or behind corporate firewalls.
The difficulty of proving this negative requires that we be especially conservative about removal. At the very least, we should demonstrate that the package is an active burden.
Its not enough to say "nobody has touched this module for ages" since stable, working code doesn't rot unless we change the language (or the std lib!) and break it.
So far, the PEPs record hasn't been too good: out of the 31 modules listed in the original draft, the PEP marks four as "keep", leaving 27 to be deprecated. So far, we've found:
the sound libraries are in heavy use by hobbyists and the professional audio-visual industry; aifc in particular is a mature, stable library that isn't break and doesn't need much attention;
cgi and cgitb are used by people who don't need a heavyweight HTML solution (see Reddit);
colorsys, fileinput and nntplib (at least) have been added to the "keep" list;
the removal of spwd (and crypt?) has been controversial.
So far, nearly 30% of the so-called "dead batteries" turn out to be not so dead after all.
I may have missed some. Nor have I even talked much about modules which I personally use occasionally, like binhex, because it's not about me its about the community. As much as I would prefer binhex to remain, if it is removed I will be disappointed but I'll make do.
Speaking of binhex, I tried to get a sense of how much of a burden it actually is. There was a comment by Guido in 2007:
https://github.com/python/cpython/commit/34a042d301d6ab88645046a6dfa6c38265ca4b39
"This is the last time I fix binhex. If it breaks again it goes in the dustbin"
which of course is Guido's perogative to say Won't Fix. Its now 2019 and it hasn't broken again, or at least it hasn't broken again sufficiently to make any difference. Serhey found one issue:
https://bugs.python.org/issue29566
but I'm not sure if that's actually a bug or not. There was a documentation bug (in the source code) in 2017:
https://bugs.python.org/issue29557
and one enhancement request to clean up the code:
https://bugs.python.org/issue34063
Other than that, Serhey touched binhex.py as part of a mass patch to almost the whole stdlib to modernise file handling to use "with".
So by my count, in 12 years since Guido's frustrated comment about binhex, it has seen:
- removal of an obsolete and ambiguous comment from the source code;
- addition of a few with blocks to modernise file handling;
- one enhancement request still outstanding;
- one possibly a bug (or maybe not) still outstanding.
I may have missed some, but we're talking about one issue per three years. How is this a maintenance burden?
-- Steven
- Previous message (by thread): [Python-Dev] PEP 594: update 1
- Next message (by thread): [Python-Dev] PEP 594: update 1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]