PEP 594: Removing dead batteries from the standard library

And one more point: The schedule doesn’t really make any sense. Why would you break compatibility in such a major way while staying in the same major version? If you’re going to make such breaking changes, shouldn’t you be waiting for 4.0? I’m sorry, but this PEP seems pretty reactionary, and not pragmatic.

5 Likes

Removing AIFF support because it’s “an old audio format from 1988” is… wow.

It’s an established, standard audio format, which is in wide use professionally. It’s not at all uncommon for e.g. sample libraries to be distributed as AIFF files. Anecdotally, the last time I used the aifc module was three weeks ago — I understand that’s not a “statistic” by any stretch, but hey.

This feels so misguided I don’t even. Please reconsider.

4 Likes

Not sure about other BSDs, but OSS is the sound API in FreeBSD - and it’s not going away anytime soon.

2 Likes

That doesn’t necessarily mean this library has to be bundled with the Python distribution, though. One point Christian makes is that with the current state of Python’s dependency management and installation tools (via setuptools, wheel and pip) there no longer is a need to bundle everything.

Instead, you’d add aifc to your requirements.txt, Pipfile or pyproject.toml file, or the install_requires list of your package setuptools configuration.

The advantage of that setup is that it makes it easier to roll out new releases, as releases are no longer tied to the much more cumbersome Python release process.

4 Likes

That would be great, but the PEP says “Substitute: none”. If this will be repackaged, then sure, everyone will just install from PyPI as needed, no issue with that.

Then again, keeping WAV support while dropping AIFF is just inconsistent.

(And the cost of just keeping both, and having backward compatibility with the existing code, is literally zero — it’s not like the aifc module needs, or indeed sees, any maintenance.)

1 Like

I note that Werkzeug doesn’t use FieldStorage (or any other part of cgi, really). Django doesn’t use FieldStorage either, but do use cgi.parse_header and cgi.valid_boundary.

Both of these functions should really be provided by the email package. There is an implementation of parse_header() in email.message.Message(), actually, so this functionality is duplicated across two different libraries in the standard lib:

>>> from cgi import parse_header
>>> from email.message import Message
>>> parse_header(h)
('application/json', {'charset': 'utf8'})
>>> m = Message()
>>> m['content-type'] = h
>>> m.get_params()
[('application/json', ''), ('charset', 'utf8')]
>>> m.get_param('charset')
'utf8'

cgi.parse_multipart() can likewise be handled by email.message; it’s all the same MIME RFC.

Or someone creates a canonical package that everyone uses, just like they rely on Python’s cgi module. That’s not really an argument for or against removing cgi from the standard library. Moving it to PyPI does have the advantage that the fix you carry in WebOb could be upstreamed faster, you don’t have to wait for everyone to upgrade their Python installation first.

Note that both Werkzeug and Django already wrote their own POST data handling.

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.

6 Likes

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.

9 Likes

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.

3 Likes