Please re-evaluate if recommendingemail for parsingmultipart/form-data is really a good idea. It has many problems, some of which may impact security of web applications:

• There is no documentation how to actually parsemultipart/form-data (e.g. from a WSGI environment) withemail. The parser expects messages to begin withMIME-Version: 1.0 and a matchingContent-Type header, which is not the case for an HTTP request. The header with the boundary is part of the HTTP headers, not the request payload. Getting this to work with a WSGI or ASGI payload is not obvious and hard to get right.
• email is way to forgiving and accepts way more than just RFC7578multipart/form-data. For example: nested multipart, invalid line breaks, invalid content disposition types, segments with missing required headers, and a ton of other stuff that may be required for email parsing but should immediately be rejected when parsingmultipart/form-data streams. That makes the email parser complex and slow (compared to a more focused parser) and intorduces a lot of surface area for potential security issues when used to parse web application user input.
• Theemail parser holds everything in memory by default, which is fine for emails but very problematic when parsing potentially large file uploads.
• Theemail parser is dangerously slow for specifically crafted input. So slow that it can be used as a denial of service attack against websites using it to parse user input. I won't go into details here, for obvious reasons.

Disclaimer: I'm the author of the multipart library.

I think a warning would stand out more than this:

Please re-evaluate if recommending email for parsing multipart/form-data is really a good idea. It has many problems, some of which may impact security of web applications:

Thanks. I copied those recommendations from the What's New section when the module was removed. I can omit this part of the page and let people find other advice to follow.

We should also make clear (as someone mentioned in Discourse) that the PyPI packages are third-party, not maintained by the CPython team.

I think a warning would stand out more than this:

I'm not sure how else you would like it to be mentioned. The first sentence (and soon one of the only sentences) is very clear.

I'm not sure how else you would like it to be mentioned.

I would just like it to stand out more by using theversionremoved,warning directive or another admonition.

I'm not sure how else you would like it to be mentioned.

I would just like it to stand out more by using theversionremoved,warning directive or another admonition.

I've added the.. deprecated-removed: directive to each page.

I've added the rest of the PEP 594 modules. Any last concerns?

Any chance of adding distutils (PEP 632)?

I guess alsoimp?

Ah, yeah,imp would be good, too. I don't think it got a PEP, so I didn't see it grepping through the list.

I've added distutils and imp.

Thanks@nedbat for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

GH-126709 is a backport of this pull request to the3.13 branch.

@nedbat do you intend to backport this to 3.12? Otherwise we shall need to retain the redirects for asynchat, asyncore, and smtpd in the 3.12 documentation only.

A

Most of the modules were removed in 3.13, so it's better to leave 3.12 as it is.

There are ~5 from 3.12, so I'd say it's worth considering if the 'version switcher' case is to be useful -- but if not I shall update the redirects PR accordingly.

A

The modules removed in 3.12 as asynchat, asyncore, distutils, imp, and smtpd. To make those behave correctly, we'd need a new PR for the docs that we'd only apply to the 3.12 branch, correct?

I don't think you'd need a new PR, just backporting this one and deleting the PEP 594 changes should work, I believe. Though maybe avoiding cherry picker would be less work, I'm not sure.

A

#126781 has the changes needed for 3.12.