email.message: Allow any header value #11574
Conversation
The allowed value depends on the used policy. For example, `EmailPolicy` allows objects with a `name` attribute, which the compat policy does not allow. This can be improved in the future, especially when TypeVar default become available.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
|
Fixes a regression introduced in #11095. |
| _HeaderType: TypeAlias = Any | ||
| _HeaderTypeParam: TypeAlias = str | Header | ||
| # Type accepted by Policy.header_store_parse. | ||
| _HeaderTypeParam: TypeAlias = str | Header | Any |
There was a problem hiding this comment.
Isn't the complex payload type from get_payload the issue for #11095 (comment) ? (which I don't think is concerned with the header type)
There was a problem hiding this comment.
Yeah, no idea why I though this was the issue. Still, this PR fixes another issue.
| _HeaderType: TypeAlias = Any | ||
| _HeaderTypeParam: TypeAlias = str | Header | ||
| # Type accepted by Policy.header_store_parse. | ||
| _HeaderTypeParam: TypeAlias = str | Header | Any |
There was a problem hiding this comment.
Since this is used exclusively for parameters/assignement, should it be
| _HeaderTypeParam: TypeAlias = str | Header | Any | |
| _HeaderTypeParam: TypeAlias = str | Header | object |
Either way maybe also with a comment explaining the use of a redundant union here (even if it's just "read TODO on Message")
often str or Header.
eh, I think that's sufficiant
There was a problem hiding this comment.
object wouldn't be correct, as it would imply that all values are correct, which isn't the case. We just can't express the accepted type properly.
|
Thanks! I don't see this PR introducing any new potential issues for users. Seems safe to merge. |
The allowed value depends on the used policy. For example,
EmailPolicyallows objects with anameattribute, which thecompat policy does not allow.
This can be improved in the future, especially when TypeVar defaults become available.