]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
gh-67022: Document bytes/str inconsistency in email.header.decode_header() and sugges...
authorDan Lenski <dlenski@gmail.com>
Sun, 15 Jun 2025 19:29:38 +0000 (12:29 -0700)
committerGitHub <noreply@github.com>
Sun, 15 Jun 2025 19:29:38 +0000 (15:29 -0400)
commit60181f4ed0e48ff35dc296da6b51473bfc553d16
tree1a18b541bea0f55398a0d46cc899a6468f63cf46
parent54e29ea4eb7b54c888fd5764eef2215535e4d862
gh-67022: Document bytes/str inconsistency in email.header.decode_header() and suggest email.headerregistry.HeaderRegistry as a sane alternative (#92900)

* gh-67022: Document bytes/str inconsistency in email.header.decode_header()

This function's possible return types have been surprising and error-prone
for the entirety of its Python 3.x history. It can return either:

1. `typing.List[typing.Tuple[bytes, typing.Optional[str]]]` of length >1
2. or `typing.List[typing.Tuple[str, None]]`, of length exactly 1

This means that any user of this function must be prepared to accept either
`bytes` or `str` for the first member of the 2-tuples it returns, which is a
very surprising behavior in Python 3.x, particularly given that the second
member of the tuple is supposed to represent the charset/encoding of the
first member.

This patch documents the behavior of this function, and adds test cases
to demonstrate it.

As discussed in bpo-22833, this cannot be changed in a backwards-compatible
way, and some users of this function depend precisely on the existing
behavior.

Add warnings about obsolescence of 'email.header.decode_header' and 'email.header.make_header' functions.

Recommend use of `email.headerregistry.HeaderRegistry` instead, as suggested
in https://github.com/python/cpython/pull/92900#discussion_r1112472177
Doc/library/email.header.rst
Lib/email/header.py
Lib/test/test_email/test_email.py