PEP 594: Removing dead batteries from the standard library

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.

There is no --disable-nis configure option. You can easily work around the problem. You could package nismodule.so in a separate subpackage or rm %{buildroot}/path/to/nismodule.so in the %install block of your spec file.

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. :slight_smile:

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

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. :frowning:

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. :slight_smile:

(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.)

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.

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.

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.

That’s actually 6 months longer than our previous deprecation policy of 18 months when we released at that frequency.

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.

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.

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 only became official after I pushed to get it completed; before this it was just convention that 18 months was the deprecation policy.

9 Likes

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. :slight_smile:

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. :frowning:

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. :slight_smile:

I honestly don’t see how that could happen technologically and still call it Python.

Red Hat does (nearly) have one (I think they have like 80% time), hence why it’s as high as 3. :wink: 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?

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.

3 Likes

Fantastic, this fact is new to me. Thanks!

@ncoghlan started the page 31. Core Developer Motivations and Affiliations — Python Developer's Guide 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.

1 Like

Given Python 3.10 beta 1 is less then one month away 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?

1 Like

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. 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/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.

In this message I give examples of the usefulness of cgi.parse_header, which has no precise alternative in other standard library modules:

(cgi.parse_multipart is similarly useful and no alternative exists.

Agreed. In the case of parse_header and parse_multipart, they ought to exist in http or a subpackage thereof. Perhaps http.parser?

4 Likes

But click itself uses optparse under the hood.

https://click.palletsprojects.com/en/latest/why/?highlight=Optparse#why-not-argparse

1 Like

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.

7 Likes

I have started a new topic for this PEP (which has been updated to target Python 3.11).

3 Likes