# PEP 594: Removing dead batteries from the standard library **URL:** \ **Category:** PEPs\ **Created:** [May 22, 2019, 10:58am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 "2019-05-22T10:58:29Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [May 22, 2019, 10:58am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/1 "2019-05-22T10:58:29Z")
> **[PEP 594 -- Removing dead batteries from the standard library](https://www.python.org/dev/peps/pep-0594/)** > > The official home of the Python Programming Language ---
**Author:** ![facundo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/facundo/32/53_2.png) [@facundo](https://discuss.python.org/u/facundo)\ **Post date:** [May 22, 2019, 7:48pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/2 "2019-05-22T19:48:10Z")
I like this PEP, everything is well explained and makes totally sense. ---
**Author:** ![andersk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/andersk/32/1010_2.png) [@andersk](https://discuss.python.org/u/andersk)\ **Post date:** [May 22, 2019, 10:46pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/3 "2019-05-22T22:46:26Z")
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](https://bugs.python.org/issue9334) 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. ---
**Author:** ![johnyesberg](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@johnyesberg](https://discuss.python.org/u/johnyesberg)\ **Post date:** [May 22, 2019, 11:59pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/4 "2019-05-22T23:59:31Z")
Great PEP. I’d tweak “TSR-80” to “TRS-80” to satisfy the history buffs. ---
**Author:** ![dbsmith.dbs83](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dbsmith.dbs83/32/1011_2.png) [@dbsmith.dbs83](https://discuss.python.org/u/dbsmith.dbs83)\ **Post date:** [May 23, 2019, 12:33am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/5 "2019-05-23T00:33:46Z")
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. ---
**Author:** ![Rapptz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rapptz/32/1012_2.png) [@Rapptz](https://discuss.python.org/u/Rapptz)\ **Post date:** [May 23, 2019, 2:01am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/6 "2019-05-23T02:01:16Z")
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. ---
**Author:** ![xistence](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/xistence/32/231_2.png) [@xistence](https://discuss.python.org/u/xistence)\ **Post date:** [May 23, 2019, 3:41am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/7 "2019-05-23T03:41:35Z")
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. ---
**Author:** ![dbsmith.dbs83](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dbsmith.dbs83/32/1011_2.png) [@dbsmith.dbs83](https://discuss.python.org/u/dbsmith.dbs83)\ **Post date:** [May 23, 2019, 3:41am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/8 "2019-05-23T03:41:40Z")
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. ---
**Author:** ![mvasilkov](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mvasilkov/32/1016_2.png) [@mvasilkov](https://discuss.python.org/u/mvasilkov)\ **Post date:** [May 23, 2019, 8:49am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/10 "2019-05-23T08:49:50Z")
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. ---
**Author:** ![trasz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/trasz/32/1020_2.png) [@trasz](https://discuss.python.org/u/trasz)\ **Post date:** [May 23, 2019, 9:24am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/11 "2019-05-23T09:24:18Z")
Not sure about other BSDs, but OSS is _the_ sound API in FreeBSD - and it’s not going away anytime soon. ---
**Author:** ![mjpieters](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mjpieters/32/710_2.png) [@mjpieters](https://discuss.python.org/u/mjpieters)\ **Post date:** [May 23, 2019, 10:02am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/12 "2019-05-23T10:02:30Z")
> [@mvasilkov](#): > > 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. 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. ---
**Author:** ![mvasilkov](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mvasilkov/32/1016_2.png) [@mvasilkov](https://discuss.python.org/u/mvasilkov)\ **Post date:** [May 23, 2019, 10:23am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/13 "2019-05-23T10:23:49Z")
> [@mjpieters](#): > > Instead, you’d add `aifc` to your `requirements.txt` 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.) ---
**Author:** ![mjpieters](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mjpieters/32/710_2.png) [@mjpieters](https://discuss.python.org/u/mjpieters)\ **Post date:** [May 23, 2019, 10:39am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/14 "2019-05-23T10:39:13Z")
> [@xistence](#): > > `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. 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`. > [@xistence](#): > > `cgi.parse_header` is also used by Django and WebOb. > > `cgi.parse_multipart` is used by Twisted. 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: ```python >>> 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. > [@xistence](#): > > 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. _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](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/formparser.py) and [Django](https://github.com/django/Django/tree/master/django/http) already wrote their own POST data handling. ---
**Author:** ![mjpieters](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mjpieters/32/710_2.png) [@mjpieters](https://discuss.python.org/u/mjpieters)\ **Post date:** [May 23, 2019, 10:44am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/15 "2019-05-23T10:44:45Z")
> [@mvasilkov](#): > > 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. 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. > [@mvasilkov](#): > > Then again, keeping WAV support while dropping AIFF is just inconsistent. 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! ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [May 23, 2019, 1:17pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/16 "2019-05-23T13:17:11Z")
> [@mvasilkov](#): > > Then again, keeping WAV support while dropping AIFF is just inconsistent. > [@mjpieters](#): > > 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. ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [May 23, 2019, 1:28pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/17 "2019-05-23T13:28:49Z")
> [@trasz](#): > > Not sure about other BSDs, but OSS is _the_ sound API in FreeBSD - and it’s not going away anytime soon. - 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. ---
**Author:** ![mtcronin99](https://avatars.discourse-cdn.com/v4/letter/m/a587f6/32.png) [@mtcronin99](https://discuss.python.org/u/mtcronin99)\ **Post date:** [May 23, 2019, 1:30pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/18 "2019-05-23T13:30:03Z")
Add zeep to the list of projects that depend on cgi.parse\_header. ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [May 23, 2019, 1:30pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/19 "2019-05-23T13:30:39Z")
> [@dbsmith.dbs83](#): > > 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. Python versioning schema does not work like this. ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [May 23, 2019, 1:33pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/20 "2019-05-23T13:33:03Z")
> [@andersk](#): > > 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](https://bugs.python.org/issue9334) 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. 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 ---
**Author:** ![trasz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/trasz/32/1020_2.png) [@trasz](https://discuss.python.org/u/trasz)\ **Post date:** [May 23, 2019, 5:30pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/21 "2019-05-23T17:30:38Z")
Makes sense, thank you. [Next page](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704.md?page=2)