Regression: ImportError for `HeaderWriteError` in long-running process post-Python update for CVE-2024-6923

Bug report

Bug description:

Pull request #122233 introduced a new class HeaderWriteError in commit 097633981879b3c9de9a1dd120d3aa585ecc2384 and imports that from email.generator.

This breaks running applications that have imported other parts of email before the update, and then try to import the generator past the update.

Now this is a bit silly, but it is what email.message.Message.as_string() does, it imports email.generator inside the function - which may happen at any point of the program run-time rather than at startup.

For example, the following pseudo-code will fail, assuming it has not generated another email earlier or manually imported the email.generator module.

import email.message
<do something for a long time, such as wait for a web form, Python is being upgraded here>
msg = <prepare a message>
msg.as_string()

A particular instance of the issue is the unattended-upgrades package in Ubuntu and Debian, which will install the security update and then may send an email and fail there due to the ImportError, see https://bugs.launchpad.net/ubuntu/+source/python3.8/+bug/2080940.

I'm wondering if it's feasible to add a workaround to the stable branches:

Cchange the email.generator module import:

from email.errors import HeaderWriteError

to graciously support the previous version email.errors:

try:
    from email.errors import HeaderWriteError
except ImportError:
    from email.errors import MessageError as HeaderWriteError

This is a safe change, existing applications, where the import fails can't be having except HeaderWriteError statements anyway.

Thanks.

CPython versions tested on:

3.12

Operating systems tested on:

No response

Lib/email/generator.py から始め、email.errors および Message.as_string() と併せて HeaderWriteError のインポートを調べてください。レポートに記載された長時間実行プロセスのシナリオを再現し、その後、互換性インポートによって ImportError が防止され、既存の動作が維持されることを確認してください。