python - email.utils.parseaddr() 现在是旧版 API。我可以继续使用它吗？

Question

我花了一些时间阅读 email 的文档。库模块。我们有一个新的 API。旧 API 现在标记为旧版。

我只有一个小型电子邮件应用程序，我希望重写它以仅使用新的更好的 API 不会很困难。但是，我找不到简单的 email.utils.parseaddr() 的简单替代品。功能。他们说:

There is no need to directly use these with the new API, since the parsing and formatting they provide is done automatically by the header parsing machinery of the new API.

email 可能是真的单独的模块，但我需要将 RFC821 样式的地址传递给 smtplib期望 from_addr 的模块函数和 to_addrs .那些 SMTP 信封地址基本上是剥离的邮件头地址和 parseaddr可以轻松创建它们:

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

新 API 中是否有相对简单的替代方案(我必须监督它)？如果不是，我是否应该期望“遗留”API 将保留在库中，或者将来会被弃用？

注:我知道 smtplib可以从邮件头中提取地址。我仍然喜欢明确地传递地址。

Answer 1

简答 : 是 ，您可以继续使用它，从现在开始。

长答案 :

PEP 4指定在支持的 API 被移除之前，它们必须被弃用；指定弃用流程；并列出所有已弃用的模块，当前的和历史的。

当前在 email 下没有记录的“旧版 API”子模块在 PEP 4 或其 Python 3.6.5 文档中被标记为“已弃用”。有一个open proposal弃用对 isdst 的支持 email.utils.localtime 中的选项，但这是唯一建议弃用 email我能够在搜索中出现的模块。

文档 elsewhere in the email package无论如何，对我来说，这表明这是一个受到相当多的关注和关心的 API，并且没有被忽视。我认为没有明显的理由担心当前记录在案的 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.

告诉我“遗留”的名称仅意味着它不再被认为是用于最常见目的的最佳、最首选的模块；没有实际的弃用警告表明 API 将很快消失。

当然，今天看不到弃用提案并不能保证它明天不会突然被弃用；我想人们可能会期望“旧版 API”更可能成为弃用的目标。但是在正式提出弃用之前，如果没有获得批准，理论上没有理由害怕使用 API；并且考虑到 Python 2 到 3 过渡期的惊人长度(它是什么， 11 years now？)，我认为您不必担心这个 API。