webob has bigger problems with cgi than just the parse_header method but that being said I don’t see a big problem with the suggested fix. I would require a little due diligence to ensure that they are actually compatible apis.

Bitter rant: due diligence because the pep isn’t very trustworthy in its analyses from the perspective of the maintainer of a very popular library that’s apparently using a library so unpopular that it’s getting dropped from the stdlib.

Any update for this issue?

Reported in red hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2245641

The title could now be changed to "ImportError: no such module cgi" :'D

Anyway, the cgi.py of 3.11 at least, contains ~1k lines in one file, of which ~700 lines are actually relevant, there is some unbelievable CGI html output garbage and some logging methods so I can understand why people want it gone, is it license-wise possible to vendor the 3.11 / 3.12 version into WebOb compat?

And with all due respect to Martijn for proposing those replacements; those replacement strategies are already in use in cgi.py as far as I can see and what remains... are those 700 lines of code.

In case there's interest, I've tested installing the legacy-cgi package with Python 3.13.0a3 and all tests pass. Branch is here: https://github.com/spiqueras/webob/tree/py3.13

Python 3.13.0b1 is out, and the cgi removal is "official" now.

any update on this?

I opened a PR to swap out cgi for the multipart package: #466

For the record, multipart is not usable at the moment because two package authors claim the same package name, neither wants to give up, and packages randomly require one or the other: defnull/multipart#53 Kludex/python-multipart#152.

FWIW there's also https://github.com/jackrosenthal/legacy-cgi which seems to be copy/paste of the CGI module. Conditionally depending on it might be the easier route to unblock 3.13 for the Pyramid ecosystem until the multipart situation is somehow resolved?

For the record, multipart is not usable at the moment because two package authors claim the same package name, neither wants to give up, and packages randomly require one or the other: defnull/multipart#53 Kludex/python-multipart#152.

Some aspects that might help here:

• The primary dependent of python-multipart is Starlette (FastAPI). There are others, but conflicts should be unlikely outside of Starlette/FastAPI projects. python-multipart is also optional and not a hard dependency for Starlette applications.
• Depending on multipart does not cause issues for python-multipart users, only the other way around. Packages take priority over single-file modules during import.

Probably not the nicest solution, but it would be possible to depend on multipart and also vendor it, then detect conflicts at runtime and fall back on the vendored version if necessary and print a warning. This would not break any existing applications for anyone, and it would also not require this project to always keep the vendored version up to date as it is only used in rare conflict situations.

I'm just afraid that testing all possible combinations would make the testsuite complex.

The multipart vs. python-multipart situation should be resolved now (see pypa/packaging-problems#818).