PEP 594: Removing dead batteries from the standard library

PEPs
1
14 Likes
2

I like this PEP, everything is well explained and makes totally sense.

3 Likes
3

Regarding getopt and optparse: I’d like to remind you all that they’re not just “deprecated but too widely used to remove”. argparse uses a nonstandard reinterpretation of Unix command line grammars that makes certain arguments impossible to express. See issue 9334 which I filed nine years ago. Since apparently it can’t or won’t be fixed with the current argparse architecture, optparse should be un-deprecated.

4 Likes
4

Great PEP. I’d tweak “TSR-80” to “TRS-80” to satisfy the history buffs.

1 Like
5

Have to disagree with some of these removals. Many of them are very small, and do not cause harm by being included in the standard library. I think that things should be removed if and only if there is good reason to (it is dangerous, there is a much better alternative, it takes up a lot of space and is not used a lot, etc
), not just because it is old.

3 Likes
6

I don’t agree with the removal of the audioop module and its removal feels out of place in this PEP. Most of these deprecation and removals tend to revolve around 3 distinct reasons as far as I can tell:

  1. They’re pure python and can be easily shipped via PyPI or copy pasted into the project.
  2. They’re antique formats that are seldom used so their maintenance is a burden
  3. They’ve been replaced by something much better or have been deprecated for a long time.

I believe audioop falls in neither of these.

  1. audioop is a C extension library with no external dependencies
  2. C extensions are difficult for beginners and many people to ship out and requires constant maintenance when providing wheels since the Python ABI changes every major release.
  3. There is no replacement to audioop anywhere as far as I can tell whether it be in PyPI or in the standard library and is used in other modules within the standard library.

In my own personal projects I use audioop for working with raw PCM data when sending this data over the wire (e.g. VoIP and the like). The nature of this module means that it’s performance sensitive and cannot be written in pure python and since this battery is included in the standard library there is no need for me (and my library users) to fiddle with extension modules to get something that used to be in the standard library.

7 Likes
7

As the maintainer of WebOb, I am unhappy to see the deprecation/removal of cgi, especially since it seems that there has been a complete disregard for functionality that is still used by others. cgi.FieldStorage is used to parse POST data, and backs all file storage inside WebOb.

As I understand it there are other frameworks that use it as well, such as Bottle.

cgi.parse_header is also used by Django and WebOb.

cgi.parse_multipart is used by Twisted.

I already carry a fix for cgi.FieldStorage in WebOb due to a bug that has not yet been fixed in Python, but I would really prefer not to carry the whole of cgi.FieldStorage by vendoring it into WebOb, and then having multiple people implement the same standards. If this PEP goes through and cgi.FieldStorage are not moved then anyone that is parsing multipart POST bodies will have to write their own, or copy an older version and hope they can get patches from other projects that have done the same.

6 Likes
8

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.

4 Likes
10

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
11

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

2 Likes
12

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
13

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
14

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.

15

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!

16

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

17
  • 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
18

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

19

Python versioning schema does not work like this.

20

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

21

Makes sense, thank you.