问题：Python的字符串格式化的许多方式-较旧的（即将被淘汰）吗？
Python至少有六种格式化字符串的方式：
In [1]: world = "Earth"
# method 1a
In [2]: "Hello, %s" % world
Out[2]: 'Hello, Earth'
# method 1b
In [3]: "Hello, %(planet)s" % {"planet": world}
Out[3]: 'Hello, Earth'
# method 2a
In [4]: "Hello, {0}".format(world)
Out[4]: 'Hello, Earth'
# method 2b
In [5]: "Hello, {planet}".format(planet=world)
Out[5]: 'Hello, Earth'
# method 2c
In [6]: f"Hello, {world}"
Out[6]: 'Hello, Earth'
In [7]: from string import Template
# method 3
In [8]: Template("Hello, $planet").substitute(planet=world)
Out[8]: 'Hello, Earth'不同方法的简要历史：
printf自从Python诞生以来，样式样式格式化就已经存在- 该
Template班是在Python 2.4中引入 - 该
format方法在Python 2.6中引入 f-strings是在Python 3.6中引入的
我的问题是：
- 是否
printf不赞成使用-style格式？ - 在中
Template class，该substitute方法是否已弃用或将要弃用？（我不是在谈论safe_substitute，据我所知它提供了独特的功能）
类似的问题以及为什么我认为它们不是重复的：
Python字符串格式：％vs.format —仅处理方法1和2，并询问哪种方法更好；我的问题明确地是关于Python Zen的弃用
字符串格式选项：优点和缺点 -仅处理问题中的方法1a和1b，答案中的方法1和2，也不考虑弃用
高级字符串格式与模板字符串的比较 -主要是关于方法1和3的，并且不解决弃用问题
字符串格式表达式（Python） -答案提到计划不推荐使用原始的’％’方法。但是，计划要弃用，待定弃用和实际弃用之间有什么区别？而且
printf-style方法甚至不会引发PendingDeprecationWarning，所以这真的会被弃用吗？该帖子也很旧，因此信息可能已过时。
也可以看看
回答 0
尽管在文档中有各种各样的迹象表明，.formatf字符串优于%字符串，但尚无可行的方案来弃用后者。
在提交的问题＃14123中：明确提及旧样式％字符串格式有一些警告，但不会很快消失。，受问题启发，表明目前没有计划弃用printf样式格式，有关%-formatting 的文档已被编辑为包含以下短语：
由于新的字符串格式语法更加灵活并且可以自然地处理元组和字典，因此建议将其用于新代码。但是，目前没有废弃过printf样式格式的计划。
（强调我的。）
此短语稍后在commit Close＃4966中删除：修改序列文档，以更好地解释现代Python的状态。这看起来似乎是一个迹象，表明不再支持%格式化的计划已经重新出现在卡上了……但是，深入研究Bug跟踪程序后，发现其意图恰恰相反。在错误跟踪器上，提交的作者描述了更改的特征，如下所示：
- 更改了描述printf样式格式与str.format方法之间关系的散文（故意消除了前者可能会消失的真正危险的暗示-认真考虑将其销毁是不切实际的）
换句话说，我们对%-formatting文档进行了两次连续更改，旨在明确强调它不会被弃用，更不用说删除了。这些文档仍然对不同类型的字符串格式的相对优点持保留意见，但他们也清楚%格式不会被弃用或删除。
更重要的是，该段落的最新更改是在2017年3月，对此进行了更改…
此处描述的格式化操作表现出各种古怪，这些古怪会导致许多常见错误（例如无法正确显示元组和字典）。使用较新的格式化字符串文字或
str.format接口有助于避免这些错误。这些替代方法还提供了更强大，灵活和可扩展的文本格式设置方法。
…对此：
此处描述的格式化操作表现出各种古怪，这些古怪会导致许多常见错误（例如无法正确显示元组和字典）。使用更新的格式化字符串文字，
str.format接口或模板字符串可能有助于避免这些错误。这些选择中的每一个都提供了自己的权衡，并带来了简单性，灵活性和/或可扩展性的好处。
请注意，从“避免使用帮助”到“可以避免使用”的变化，以及关于.formatf和弦的清晰建议如何被蓬松，模棱两可的散文所取代，有关每种样式如何“提供自己的取舍和好处”。也就是说，不仅不再正式弃用卡片，而且当前的文档公开承认%格式至少比其他方法具有一些“好处”。
从这一切中我可以推断出，弃用或删除%格式的运动不仅步履蹒跚，而且被彻底永久地击败。
回答 1
新.format()方法旨在替换旧的%格式语法。后者已经不再强调，（但没有正式弃用尚未）。方法文档指出：
字符串格式化的这种方法是在Python 3的新标准，并应首选的
%格式化中所描述的字符串的格式化操作在新的代码。
（强调我的）。
为了保持向后兼容性，并让您更容易过渡，旧格式已经被留在原地现在。根据最初的PEP 3101提案：
向后兼容
可以通过保留现有机制来保持向后兼容性。新系统不会与现有字符串格式化技术的任何方法名称发生冲突，因此这两个系统可以共存，直到需要弃用旧系统为止。
请注意，直到该淘汰旧系统为止；它尚未被弃用，但是只要您编写新代码，就将使用新系统。
新系统的一个优点是您可以结合使用旧%格式化程序的元组和字典方法：
"{greeting}, {0}".format(world, greeting='Hello')并可以通过 object.__format__()用于处理各个值格式钩子进行。
请注意，旧系统具有%和Template类，后者允许您创建添加或更改其行为的子类。新型系统具有Formatter一流填充相同细分市场。
Python 3进一步远离了弃用，而是在printf-style String Formatting部分中给您警告：
注意：此处描述的格式化操作表现出各种古怪，导致许多常见错误（例如未能正确显示元组和字典）。使用较新的格式化字符串文字或
str.format()接口有助于避免这些错误。这些替代方法还提供了更强大，灵活和可扩展的文本格式设置方法。
Python 3.6还添加了格式化的字符串文字，将表达式内联到格式字符串中。这些是使用内插值创建字符串的最快方法，应使用它，而不是str.format()在可以使用文字的任何地方。
回答 2
%尽管有其他答案，但不建议使用字符串格式的运算符，并且不会删除该运算符。
每次在Python开发列表中提出该主题时，都会有一个关于哪个更好的参数，但是对于是否要删除经典方法却没有争议-它会一直存在。尽管在PEP 3101上有说明，但Python 3.1来了又去了，%格式化仍然存在。
保持经典风格的说法很明确：它很简单，很快，可以快速完成简短的事情。使用该.format方法并不总是那么容易理解-几乎没有人-即使在核心开发人员中，也可以使用所提供的完整语法，.format而无需查看参考资料甚至在2009年，就有这样的消息：http：// mail。 python.org/pipermail/python-dev/2009-October/092529.html 几乎没有出现该主题。
2016年更新
在当前的Python开发版本（将成为Python 3.6）中，有第三种字符串内插方法，如PEP-0498所述。它定义了一个新的报价前缀f""（除了当前的u""，b""和r""）。
给字符串加上前缀f将在运行时在字符串对象上调用一个方法，该方法将自动将当前作用域中的变量插入到字符串中：
>>> value = 80
>>> f'The value is {value}.'
'The value is 80.'回答 3
圭多对此的最新立场似乎在这里指出：
PEP 3101：字符串格式化的新方法
用于内置字符串格式化操作的新系统取代了％字符串格式化运算符。（但是，仍然支持％运算符；它将在Python 3.1中弃用，并在以后的某个时间从语言中删除。）有关完整说明，请阅读PEP 3101。
而PEP3101本身，它有最后的修改可以追溯到（周五，2011年9月30日），这样的晚的，一个没有进步，我想。
回答 4
在查看较旧的Python文档和PEP 3101时，有一条语句表示将来将不推荐使用％运算符并将其从该语言中删除。在下面的语句是在Python文档的Python 3.0，3.1和3.2：
由于str.format（）很新，因此许多Python代码仍然使用％运算符。但是，由于最终会从该语言中删除这种旧的格式设置样式，因此通常应使用str.format（）。
如果转到Python 3.3和3.4文档中的同一部分，您将看到该语句已被删除。我也无法在文档中的任何其他地方找到任何其他声明，表明该运算符将不推荐使用或从该语言中删除。还需要注意的是，PEP3101两年半没有进行过修改（2011年9月30日，星期五）。
更新资料
PEP461接受将％格式添加到字节和字节数组中，并且应该是Python 3.5或3.6的一部分。这是％运算符还活着而且在踢的另一个迹象。