email.utils.parseaddr()现在已经是遗留API了。我能继续使用它吗？

Question

我花了一些时间阅读了电子邮件库模块的文档。我们有一个新的API，旧的API现在已被标记为遗留。

我只有一个小的电子邮件应用程序，我希望重写它以仅使用新的和更好的API不难。然而，我无法找到一个简单的替代简单的email.utils.parseaddr()函数。他们说：

由于新API的头部解析机制自动完成了它们提供的解析和格式化，因此没有必要直接使用它们。

这可能是关于email模块的真相，但我需要将RFC821样式地址传递给期望from_addr和to_addrs的smtplib模块函数。那些SMTP信封地址基本上是剥离的消息头地址，parseaddr可以轻松创建它们：

smtp_addr = email.utils.parseaddr(email_addr)[1]

在新的API中是否有类似简单的替代方案（我可能已经忽略了它）？如果没有，那么我应该期望“遗留”的API会留在库中还是在未来被废弃？

注意：我知道smtplib可以从消息头中提取地址。但我仍然喜欢显式地传递地址。

- VPfB

---

如果“不能”意味着物理上的不可能，那么是的，你可以，为什么不呢？如果你问是否应该继续使用它，那么答案是基于个人观点的，恐怕我无法回答。 - DYZ

是的，你说得对，根据使用情况，应该做出决策，例如软件更新的频率。 - mdeora

Answer 1

简短回答：是的，目前可以继续使用。 详细回答： PEP 4 规定在支持的 API 被删除之前，必须先将其标记为“已弃用”，并指定了一个弃用的过程，并列出了所有已弃用的模块、当前和历史的。

在 Python 3.6.5 文档中，email 下文档中未标记任何“Legacy API”子模块为“已弃用”。在搜索中，我找到了一个开放提案，旨在弃用 email.utils.localtime 中的 isdst 选项的支持，但这是我能找到的关于 email 模块的唯一提议弃用。 email 包中的其他文档表明，至少在我看来，这是一个受到相当关注和关心的 API，并不被忽视。我没有发现任何明显的理由担心当前文档中的 API，即使是“Legacy API”部分中的 API，很快就会被弃用。

例如，在email.mime中的此备注：

This module is part of the legacy (Compat32) email API. Its functionality is partially replaced by the contentmanager in the new API, but in certain applications these classes may still be useful, even in non-legacy code.

告诉我，“legacy”这个称号只意味着它不再被认为是用于最常见目的的最佳和最优选的模块；没有实际的弃用警告表明该 API 即将消失。

当然，今天看不到弃用提案并不能保证它不会突然被弃用；我想人们可能会期望“Legacy API”更有可能成为弃用的目标。但在正式提出弃用之前，如果没有得到批准，理论上没有理由担心使用 API；考虑到 Python 2 到 3 过渡期的惊人长度（现在是 11 年了？），我认为您可以放心使用此 API，无需担心。

- wberry