`email.policy.compat32` does not work as `policy` for `email.message.MIMEPart`

[dkg]

Bug report

Bug description:

#!/usr/bin/python3

from email.message import MIMEPart
from email.policy import compat32

m = MIMEPart(policy=compat32)
m.set_content(b'\x00'*100, 'image', 'phg')

This raises the following exception:

Traceback (most recent call last):
  File "[…]/test.py", line 7, in <module>
    m.set_content(b'\x00'*100, 'image', 'phg')
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/message.py", line 1136, in set_content
    content_manager = self.policy.content_manager
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Compat32' object has no attribute 'content_manager'

This is with python3 3.13.3-1 on debian.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[medmunds]

It's not entirely clear to me that this should work. (Or why you would want to do it.) MIMEPart is specifically part of the modern email API; compat32 is the legacy API.

Note that you can construct a MIMEPart with its default policy and then flatten it using compat32:

Python 3.13.2...
>>> from email.message import MIMEPart
>>> from email.policy import compat32
>>> m = MIMEPart()
>>> m.set_content(b'\x00'*100, 'image', 'phg')
>>> m.as_bytes(policy=compat32)
b'Content-Type: image/phg\nContent-Transfer-Encoding: base64\n\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\n'

Perhaps the documentation for email.message.EmailMessage (which is shared by MIMEPart) should clarify the policy argument should not be a legacy Compat32 policy, and the documentation for email.policy.compat32 should clarify that it can be passed to a generator to flatten modern EmailMessage objects, but it cannot reliably be used to create them.

[dkg]

fwiw, it is not clear at all to me that some of these classes are deprecated and others are preferred, or that there is some pool of functions/methods/classes that will work together but that pool is disjoint from some other pool of other functions/classes/methods.

If there were clearer documentation about that distinction, i'd like to think i would have read it and avoided these particular concerns. And if there is such documentation, then perhaps the Exceptions raised could point directly at it for further clarity.