PEP 594: Removing dead batteries from the standard library

The Substitute entries are there to note if there are other standard library packages that can cover the functionality, not if the package won’t see a release on PyPI or doesn’t already have alternatives there. I’m not sure what argument you are making with that.

I can see your point there; I think Christian was simply not aware that AIFF is still widely used. Personally, I see that as an argument to drop WAV support too!

Yes, it’s inconsistent.
But it’s inconsistent for good reasons. The reasons are spelled out in the PEP text two times.

  • The module is pretty much unmaintained and have not seen any improvements, e.g. OSSv4 support. Almost all commits in the last 8 years are related to project wide code cleanups. Serhiy and Victor have spent time on the module although they are not FreeBSD users.
  • CPython contains no bindings for Windows and ALSA. IMHO OSS is not special enough to have it in the core.

It would be more beneficial for everybody if the module would be picked up and maintained by the FreeBSD community. It would free resources for CPython devs and get actual users a better experience.

1 Like

Add zeep to the list of projects that depend on cgi.parse_header.

Python versioning schema does not work like this.

Thanks for you feedback, but it’s slightly off topic. Could you please look for an existing bug on our bug tracker for de-deprecation of the optparse module and creaet a new one in case there is none? Thanks

Makes sense, thank you.

I’d like to suggest one principle that makes particular modules valuable in the standard library.

A lot of the value of a large standard library is in making it possible to write programs without any dependencies from PyPI. Once you’ve set up requirements.txt and a virtualenv and all, adding another dependency is pretty cheap, but the first one is expensive.

So modules are particularly valuable in the standard library if they’re likely to be used in small scripts or ‘glue’ code, or when you’re using a bit of Python in a project that’s mostly in another language.

1 Like

I suggest keeping the pipes module.

I don’t think it has been a great success, but subprocess doesn’t yet have a replacement for what it does, and its main use is when you find your shell script has grown too big and you want to start to rewrite it in Python.

That’s exactly the situation where you don’t want to have to set up a virtualenv.

1 Like

I suggest keeping the cgi module.

Note that it doesn’t really have anything to do with the CGI protocol (so the bit of the PEP that talks about CGI being inefficient is a little out of place).
Rather it’s for dealing with the way browsers represent form data.

There’s no alternative for that in the standard library, and it’s very much the sort of thing that you sometimes want to do in a small standalone CGI or WSGI script. Certainly I have scripts like that using it, and giving each one a virtualenv would be a pain.


Would you mind providing a concrete example? From my experience, common shell script operations can be done in comparable amounts of code with subprocess (plus some misc constructs).

Again, examples are needed. As already discussed above, many operations do have alternatives, and those that don’t should be added/moved to other modules exactly because they are not specific to CGI.

It doesn’t cause you harm by them being included in the stdlib, but it does harm/cost us core developers who have to keep them functioning. And nothing, no matter how small, is free to maintain. Even people filing feature requests that won’t be addressed take time to close (and remember we have over 1,000 open PRs right now so there’s a scale issue we are dealing with). Code is simply just not free in terms of time and we already have so much other code as a team to keep functioning that we can’t keep every module that we have accumulated running to a standard we are happy with, so we need to cut somewhere.

So while we understand that Python’s popularity guarantees that every module in the stdlib is used by someone, this list is trying to pull out the extent of what modules we can reasonably ask the community to take over maintenance for instead of shouldering us core devs with the burden forever.


This is incorrect. If you look at the PEP in question, you’ll notice that most of what goes into the Substitute field are links to existing PyPI packages.

When deciding on these modules, did anyone look at how much time they actually take to maintain, in terms of # of issues either filed or closed?

My experience is that, while not widely used, it’s still valuable to have a few of these batteries included - it may only be on occasion that they’re ultimately useful, but to those of us that occasionally use them, they’re invaluable.

Heck - if the existing things (e.g. cgi) are currently so terrible that they need to be tossed out and re-written from scratch, rather than just say, “Let’s get rid of these” Why not say instead, “This is terrible and we’d love to keep it around, but it needs a complete overhaul. To help out with the overhaul, go . Otherwise, this module will be deprecated & removed.”

That way it gives people who have an investment the opportunity to put their money/time where their mouth is - to spend some time actually fixing the problems.


Isn’t this already (part of) the message this PEP sends? A draft PEP is posted so people can discuss whether modifications are needed, and guaranteeing a module is important and well-maintained is certainly one of the valid arguments to keep it from being included in the PEP.


I’ve had a harder look at the pipes module.

It doesn’t provide a way to check the exit status of the pipeline members, which makes it an easy way for people to write buggy code.

Also some of its core features are undocumented.

So I think it’s better off gone. Sorry for the noise.

(I think better pipeline handling would be a fine thing for the standard library to include, but that’s obviously not a matter for this thread.)

1 Like

I’m not sure if you’re asking for example code or example uses. I’m talking about FieldStorage, which makes up most of cgi's code.

An example script I have is a form which offers a couple of input boxes and a submit button, and uses them to select logs to display.

Moving FieldStorage to somewhere with a better name than cgi seems like a sensible idea, but it’s not what this PEP is proposing.

I suggest keeping the crypt module.

I think it should be understood as a module giving access to the OS-provided crypt(3), rather than a general purpose password hashing utility (it’s documented under “Unix specific services” rather than “Cryptographic Services”, after all).

Python includes wrappers for most traditional libc functions, and crypt is still sometimes useful because it can give the same answer as other software (probably not written in Python) running on the same machine.

It would probably be worth updating the module’s documentation to make it clearer that this isn’t what you want if you’re not trying to interoperate with some existing password store.

I’m not thinking of the system password file, rather services like Dovecot or Apache.

Also, if you’re running a service that’s been around for many years, the usual way to handle an upgrade to the hashing format is to re-hash passwords when users log in. So if you started out using one of the crypt formats, you may still need it. (But this doesn’t sound like the sort of project that would have great difficulty adding a dependency from PyPI.)

1 Like

In large part we needed the PEP to flush out the people who care about these modules, since leaving them unmaintained hasn’t been enough to get volunteers to look after them.

The easiest way to make sure it doesn’t get removed is to volunteer to maintain the module. A post on python-dev is a good starting point for doing that.


(Okay, maybe not the easiest, but certainly the least likely argument to be ignored.)