# 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:** 19\ **Page:** 6
**Author:** ![CendioOssman](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cendioossman/32/3427_2.png) [@CendioOssman](https://discuss.python.org/u/CendioOssman)\ **Post date:** [February 4, 2021, 3:45pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/104 "2021-02-04T15:45:19Z")
> [@steve.dower](#): > > Deprecation is not the same as removal, you’re welcome to keep using it even as it is marked deprecated. Just be aware that it will likely bit-rot, and if you really need it to keep working, you may need to implement workarounds. Right. It’s indeed the removal that’s the key issue here. My bad. The PEP currently states that asyncore should be removed by 3.10 (which doesn’t seem to be happening). But we’d very much like it to stay around for a couple more releases after that as well. 🙂 > [@tiran](#): > > Why does asyncore have to stay in the stdlib? You could ask your vendor to package and maintain asyncore as a separate package. After all you are paying a vendor for an enterprise experience. Unfortunately I doubt we have the clout to get all the major distributions to do something like that. ---
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fdrake/32/19_2.png) [@fdrake](https://discuss.python.org/u/fdrake)\ **Post date:** [February 4, 2021, 4:11pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/105 "2021-02-04T16:11:28Z")
> [@CendioOssman](#): > > Unfortunately I doubt we have the clout to get all the major distributions to do something like that. Don’t be surprised if the distro maintainers are open to things like this; they want people to continuing supporting their work, so I’d expect they’d be interested in making staying on their distribution as easy as possible. Ask them to provide the needed package, and the worst that can happen is they’ll say no. You can then vendor `asyncore` and anything else you still need. -Fred ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 4, 2021, 7:34pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/106 "2021-02-04T19:34:19Z")
> [@CendioOssman](#): > > But we’d very much like it to stay around for a couple more releases after that as well. Our current deprecation policy is two releases, so if this is deprecated in 3.10 then it won’t be removed until 3.12 which is due to be released in October 2023. ---
**Author:** ![CendioOssman](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cendioossman/32/3427_2.png) [@CendioOssman](https://discuss.python.org/u/CendioOssman)\ **Post date:** [February 5, 2021, 4:28pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/107 "2021-02-05T16:28:03Z")
> [@brettcannon](#): > > Our current deprecation policy is two releases, so if this is deprecated in 3.10 then it won’t be removed until 3.12 which is due to be released in October 2023. From the point of view of an application developer, I’m afraid that sounds a bit too aggressive. I’m concerned we could end up in a situation where we cannot write Python code that works on all concurrent distributions, e.g on both RHEL 7 and Ubuntu 22.04. I’d hate to be put in the nasty situation of having to shut the door on a large group of users. ☹ Ideally I’d like to see backwards compatibility on a time scale similar to the life cycle of the distributions. I.e. 10 years. So this is a humble plea from one of your otherwise very happy users to re-evaluate that policy and see if it can be relaxed. 🙂 (If the distributions start getting better at upgrading Python this would not be needed of course. So this is assuming the current state of things will persist.) ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [February 5, 2021, 4:37pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/108 "2021-02-05T16:37:08Z")
As someone else said, though, you could vendor your own version of `asyncore`. Since `asyncore` is a single pure Python module and has received almost no change over recent years, that shouldn’t be too difficult. ---
**Author:** ![michel-slm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/michel-slm/32/156_2.png) [@michel-slm](https://discuss.python.org/u/michel-slm)\ **Post date:** [February 5, 2021, 8:46pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/109 "2021-02-05T20:46:59Z")
Speaking as a Fedora maintainer, the barrier of entry for contributing is quite low. I’m more than happy to help someone get started. If some package in Fedora already depends on `asyncore` it’s likely its maintainers will notice and get it packaged. If not, though, then the best bet is to get involved and package it. Vendoring is normally frowned upon. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 5, 2021, 9:07pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/110 "2021-02-05T21:07:18Z")
I want to start off by saying this response is not meant to come off as angry, but I want to dispel some misconceptions about how much actual bandwidth we have as a core team, and so asking for something that you all might seem as small in actuality isn’t and to encourage you all to use vendors with support contracts for Python if you have specific needs that you absolutely have to make sure are met. > [@CendioOssman](#): > > From the point of view of an application developer, I’m afraid that sounds a bit too aggressive. That’s actually 6 months longer than our previous deprecation policy of 18 months when we released at that frequency. > [@CendioOssman](#): > > I’d hate to be put in the nasty situation of having to shut the door on a large group of users. As others have stated, you can always vendor so there’s really nothing going on here that going “to shut the door on a large group of users” for whom those users couldn’t fix themselves. > [@CendioOssman](#): > > Ideally I’d like to see backwards compatibility on a time scale similar to the life cycle of the distributions. I.e. 10 years. That was called Python 2.7 and it sucked. If you would like support that long then you should probably contact your Linux vendor or Python distribution vendor for a support contract. But for me, supporting Python versions for 5 years is already a lot of work that doesn’t exactly inspire me to spend my free time on weekends away from family and friends to make happen; 10 years is definitely not going to “spark joy” and cause me to either not backport bugs or not even bother fixing bugs. > [@CendioOssman](#): > > So this is a humble plea from one of your otherwise very happy users to re-evaluate that policy and see if it can be relaxed. I appreciate your position, but I bet your team gets more paid time for your product than the entire Python core team has people paid to work on it (our best guess is if you total everyone up it’s about 3 devs’ worth of time). And that’s for supporting CPython **and** the entire stdlib. But to be very specific, the minimum two year deprecation policy was debated publicly and was agreed upon to be reasonable. And [that PEP](https://www.python.org/dev/peps/pep-0387/) only became official after I pushed to get it completed; before this it was just convention that 18 months was the deprecation policy. ---
**Author:** ![CendioOssman](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cendioossman/32/3427_2.png) [@CendioOssman](https://discuss.python.org/u/CendioOssman)\ **Post date:** [February 8, 2021, 9:00am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/111 "2021-02-08T09:00:31Z")
> [@brettcannon](#): > > As others have stated, you can always vendor so there’s really nothing going on here that going “to shut the door on a large group of users” for whom those users couldn’t fix themselves. I was thinking more about possible future changes where it might not always be possible to do so. And with some luck, and depending on how radically Python changes, that might not occur in practice. 🙂 > [@brettcannon](#): > > I appreciate your position, but I bet your team gets more paid time for your product than the entire Python core team has people paid to work on it (our best guess is if you total everyone up it’s about 3 devs’ worth of time). And that’s for supporting CPython **and** the entire stdlib. Oh? Given how much Red Hat uses Python for their own software I blindly assumed they would have at least one full time employee on your team. And similarly for the other major commercial distributions. I’m sorry to hear that is not the case. ☹ > [@brettcannon](#): > > …10 years is definitely not going to “spark joy” and cause me to either not backport bugs or not even bother fixing bugs. Just in case there was a misunderstanding; it isn’t fully maintained releases with bug fixes that we’d ideally like to see, but rather when something gets removed then its replacement has been around for some time. E.g. in the asyncore case, assuming it gets removed in 2023 then asyncio would ideally have been available since 2013. And I fully understand this not being at the top of your list if this is a free time project. 🙂 ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 9, 2021, 1:38am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/112 "2021-02-09T01:38:26Z")
> [@CendioOssman](#): > > I was thinking more about possible future changes where it might not always be possible to do so. And with some luck, and depending on how radically Python changes, that might not occur in practice. I honestly don’t see how that could happen technologically and still call it Python. > [@CendioOssman](#): > > Given how much Red Hat uses Python for their own software I blindly assumed they would have at least one full time employee on your team. And similarly for the other major commercial distributions. I’m sorry to hear that is not the case. Red Hat does (nearly) have one (I think they have like 80% time), hence why it’s as high as 3. 😉 Everyone else gets like 20% time or time as necessary. ---
**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:** [February 9, 2021, 5:28pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/113 "2021-02-09T17:28:43Z")
> [@brettcannon](#): > > Red Hat does (nearly) have one (I think they have like 80% time), hence why it’s as high as 3. 😉 Everyone else gets like 20% time or time as necessary. I wouldn’t even know how to count it properly… Red Hat employs three active core devs + a couple of engineers that contribute to Python infrastructure e.g. Buildbots. I don’t have a fixed amount of time for Python dev, it fluctuates between 0% and 100%. Other major employers of core devs and core infrastructure are Microsoft (+LinkedIn), Google, Bloomberg, and self-employed. Did I miss somebody or a company? ---
**Author:** ![uranusjr](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/uranusjr/32/103_2.png) [@uranusjr](https://discuss.python.org/u/uranusjr)\ **Post date:** [February 9, 2021, 5:36pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/114 "2021-02-09T17:36:13Z")
From what I know, at least one core dev is employed by Huawei and openly (to their employer) using company resource and time to contribute to CPython, although the company never acknowledge the fact they’re doing so as Huawei employees. I suspect there are other companies in the same category. ---
**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:** [February 9, 2021, 5:56pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/115 "2021-02-09T17:56:07Z")
Fantastic, this fact is new to me. Thanks! @ncoghlan started the page [31. Core Developer Motivations and Affiliations — Python Developer's Guide](https://devguide.python.org/motivations/) a while ago. Looks like it hasn’t been updated in a while. Some of our new core devs may not even know about the page. ---
**Author:** ![johnthagen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johnthagen/32/3780_2.png) [@johnthagen](https://discuss.python.org/u/johnthagen)\ **Post date:** [April 6, 2021, 10:47am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/116 "2021-04-06T10:47:23Z")
Given [Python 3.10 beta 1 is less then one month away](https://www.python.org/dev/peps/pep-0619/#schedule) I was curious if there was any traction left to get this in. This seems like some important clean up. Is anything in particular still holding this up? ---
**Author:** ![dlenski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dlenski/32/5721_2.png) [@dlenski](https://discuss.python.org/u/dlenski)\ **Post date:** [December 16, 2021, 10:46pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/117 "2021-12-16T22:46:57Z")
> [@xistence](#): > > `cgi.parse_header` is also used by Django and WebOb. > > `cgi.parse_multipart` is used by Twisted. Big 👍. At `$BIGCORP` jobs, I’ve repeatedly had to write or maintain proxy(ish) code which intercepts HTTP requests and rewrites them in some other form. To my knowledge, `cgi.parse_header` is the standard library’s only way to [parse an HTTP header like `Content-Type` in a standard-compliant way](https://datatracker.ietf.org/doc/html/rfc2616#section-14.17). That is, a header that that contains a “main” value (e.g. `text/json`) in addition to arbitrary key-value pairs. For example: ```py >>> from cgi import parse_header >>> print(parse_header('Content-type: text/html; charset=UTF-8; foo="blick; block=bing"')) ('Content-type: text/html', {'charset': 'UTF-8', 'foo': 'blick; block=bing'}) ``` (@mjpieters points out that `email.message.Message` contains equivalent functionality, but the interface is not nearly as clean.) Retaining a straightforward way to invoke the _functionality_ of `parse_header` and `parse_multipart` is very important. Seems like `http`, or a submodule thereof, would be the more natural home for these functions. It’d be good to note them in the PEP. ---
**Author:** ![dlenski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dlenski/32/5721_2.png) [@dlenski](https://discuss.python.org/u/dlenski)\ **Post date:** [December 16, 2021, 11:04pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/118 "2021-12-16T23:04:07Z")
In this message I give examples of the usefulness of `cgi.parse_header`, which has no precise alternative in other standard library modules: > [@PEP 594: Removing dead batteries from the standard library](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/117): > > Big +1. At $BIGCORP jobs, I’ve repeatedly had to write or maintain proxy(ish) code which intercepts HTTP requests and rewrites them in some other form. To my knowledge, cgi.parse\_header is the standard library’s only way to [parse an HTTP header like Content-Type in a standard-compliant way](https://datatracker.ietf.org/doc/html/rfc2616#section-14.17). That is, a header that that contains a “main” value (e.g. text/json) in addition to arbitrary key-value pairs. For example: \>\>\> from cgi import parse\_header \>\>\> print(parse\_header('Content-type: text/ht… (`cgi.parse_multipart` is similarly useful and no alternative exists. > [@uranusjr](#): > > Moving to somewhere with a better name than `cgi` seems like a sensible idea, but it’s not what this PEP is proposing. Agreed. In the case of `parse_header` and `parse_multipart`, they ought to exist in `http` or a subpackage thereof. Perhaps `http.parser`? ---
**Author:** ![rednafi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rednafi/32/2934_2.png) [@rednafi](https://discuss.python.org/u/rednafi)\ **Post date:** [December 30, 2021, 12:38am UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/119 "2021-12-30T00:38:14Z")
But click itself uses `optparse` under the hood. [https://click.palletsprojects.com/en/latest/why/?highlight=Optparse#why-not-argparse](https://click.palletsprojects.com/en/latest/why/?highlight=Optparse#why-not-argparse) ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [December 30, 2021, 8:26pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/120 "2021-12-30T20:26:42Z")
No it doesn’t. It uses a modified copy, it doesn’t import the standard module. And I’m working on getting rid of that too. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 4, 2022, 11:52pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/121 "2022-02-04T23:52:34Z")
I have started a new topic for this PEP (which has been updated to target Python 3.11). > [@PEP 594, take 2: Removing dead batteries from the standard library](https://discuss.python.org/t/pep-594-take-2-removing-dead-batteries-from-the-standard-library/13508): > > I’m reviving this PEP w/ Christian. It has been updated to target Python 3.11. Since this has already been heavily discussed in [PEP 594: Removing dead batteries from the standard library](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704) , my expectation is to take this to the steering council shortly, barring any major objections that come up in this topic. PEP: 594 Title: Removing dead batteries from the standard library Author: Christian Heimes \, Brett Cannon \ Discussions-To: https://discuss.… ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 4, 2022, 11:52pm UTC](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/122 "2022-02-04T23:52:38Z")
Closed on February 4, 2022, 11:52pm UTC > [@PEP 594, take 2: Removing dead batteries from the standard library](https://discuss.python.org/t/pep-594-take-2-removing-dead-batteries-from-the-standard-library/13508): > > I’m reviving this PEP w/ Christian. It has been updated to target Python 3.11. Since this has already been heavily discussed in [PEP 594: Removing dead batteries from the standard library](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704) , my expectation is to take this to the steering council shortly, barring any major objections that come up in this topic. PEP: 594 Title: Removing dead batteries from the standard library Author: Christian Heimes \, Brett Cannon \ Discussions-To: https://discuss.… [Previous page](https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704.md?page=5)