Python a au moins six façons de formater une chaîne:
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'
Un bref historique des différentes méthodes:
printf
- le formatage de style existe depuis l'enfance de PythonsTemplate
a été introduite dans Python 2.4format
a été introduite dans Python 2.6f
- les chaînes ont été introduites dans Python 3.6Mes questions sont:
printf
est-il obsolète ou va-t-il être obsolète?Template class
, la méthode substitute
est-elle obsolète ou va-t-elle être obsolète? (Je ne parle pas de safe_substitute
, qui, si je comprends bien, offre des capacités uniques)Questions similaires et pourquoi je pense que ce ne sont pas des doublons:
Formatage des chaînes Python:% vs .format - ne traite que les méthodes 1 et 2, et demande laquelle est la meilleure; ma question concerne explicitement la dépréciation à la lumière du Zen de Python
Options de formatage des chaînes: avantages et inconvénients - ne traite que les méthodes 1a et 1b dans la question, 1 et 2 dans la réponse, et aussi rien sur la dépréciation
formatage de chaîne avancé vs chaînes de modèle - principalement sur les méthodes 1 et 3, et ne traite pas de la dépréciation
Expressions de formatage de chaînes (Python) - la réponse mentionne que l'approche originale '%' devrait être déconseillée . Mais quelle est la différence entre prévu pour être obsolète , en attente de dépréciation et réel dépréciation ? Et la méthode de style printf
ne soulève même pas un PendingDeprecationWarning
, est-ce que cela va vraiment être déconseillé? Ce message est également assez ancien, donc les informations peuvent être obsolètes.
Bien qu'il existe diverses indications dans les documents que .format
et les chaînes f sont supérieures à %
cordes, il n'y a aucun plan de survie pour déprécier ce dernier.
En commit Problème # 14123: mentionne explicitement que l'ancien formatage de chaîne% comporte des mises en garde mais ne disparaîtra pas de si tôt. , inspiré par le problème = Indiquez qu'il n'y a actuellement aucun plan pour déconseiller la mise en forme de style printf , les documents sur %
- le formatage a été modifié pour contenir cette phrase:
Comme la nouvelle syntaxe de mise en forme des chaînes est plus flexible et gère naturellement les tuples et les dictionnaires, elle est recommandée pour le nouveau code. Cependant, il n'est actuellement pas prévu de déprécier la mise en forme de style printf .
(Je souligne.)
Cette phrase a été supprimée plus tard, en commit Fermer # 4966: réorganiser les documents de séquence afin de mieux expliquer l'état de Python moderne . Cela peut sembler être un signe qu'un plan de dépréciation %
le formatage était de retour sur les cartes ... mais plonger dans le traqueur de bogues révèle que l'intention était l'inverse. Sur le bug tracker, l'auteur du commit caractérise le changement comme ça :
- changé la prose qui décrit la relation entre la mise en forme de style printf et la méthode str.format (en supprimant délibérément l'implication que la première menace de disparaître - il n'est tout simplement pas pratique pour nous d'envisager sérieusement de la tuer)
En d'autres termes, nous avons apporté deux modifications consécutives au %
- formatage des documents destinés à souligner explicitement qu'il sera pas obsolète, et encore moins supprimé. Les documents restent partagés sur les mérites relatifs de différents types de formatage de chaînes, mais ils sont également clairs sur le %
- le formatage ne sera ni obsolète ni supprimé.
De plus, le dernière modification apportée à ce paragraphe , en mars 2017, l'a changé depuis ...
Les opérations de formatage décrites ici présentent une variété de bizarreries qui conduisent à un certain nombre d'erreurs courantes (telles que le fait de ne pas afficher correctement les tuples et les dictionnaires). Utilisation des nouveaux littéraux de chaîne formatés ou du
str.format
l'interface permet d'éviter ces erreurs. Ces alternatives fournissent également des approches plus puissantes, flexibles et extensibles pour formater le texte.
... pour ça:
Les opérations de formatage décrites ici présentent une variété de bizarreries qui conduisent à un certain nombre d'erreurs courantes (telles que le fait de ne pas afficher correctement les tuples et les dictionnaires). En utilisant les nouveaux littéraux de chaîne formatés, le
str.format
l'interface ou les chaînes de modèle peuvent aider à éviter ces erreurs. Chacune de ces alternatives offre ses propres compromis et avantages de simplicité, de flexibilité et/ou d'extensibilité.
Notez que le passage de "aide à éviter" à "peut aider à éviter" et comment la recommandation claire de .format
et les chaînes f ont été remplacées par une prose moelleuse et équivoque sur la façon dont chaque style "offre ses propres compromis et avantages". Autrement dit, non seulement une dépréciation formelle n'est plus sur les cartes, mais les documents actuels reconnaissent ouvertement que %
le formatage présente au moins certains "avantages" par rapport aux autres approches.
Je déduirais de tout cela que le mouvement pour déprécier ou supprimer %
le formatage a non seulement faibli, mais a été complètement et définitivement défait.
La nouvelle méthode .format()
est destinée à remplacer l'ancienne syntaxe de formatage %
. Ce dernier a été minimisé, (mais pas officiellement obsolète pour l'instant). La documentation de la méthode le dit:
Cette méthode de formatage des chaînes est le nouveau standard de Python 3, et devrait être préféré au
%
formatage décrit dans Opérations de formatage de chaîne dans le nouveau code.
(Je souligne).
Pour maintenir la compatibilité descendante et faciliter la transition, l'ancien format a été laissé en place pour l'instant. D'après l'original proposition PEP 3101 :
Rétrocompatibilité
La rétrocompatibilité peut être maintenue en laissant les mécanismes existants en place. Le nouveau système ne se heurte à aucun des noms de méthode des techniques de formatage de chaînes existantes, de sorte que les deux systèmes peuvent coexister jusqu'à ce qu'il soit temps de déprécier l'ancien système.
Notez le jusqu'à ce qu'il soit temps de déprécier l'ancien système; il n'est pas obsolète, mais le nouveau système doit être utilisé chaque fois que vous écrivez nouveau code.
Le nouveau système a comme avantage que vous pouvez combiner l'approche Tuple et dictionnaire de l'ancien formateur %
:
"{greeting}, {0}".format(world, greeting='Hello')
et est extensible via le crochet object.__format__()
utilisé pour gérer le formatage des valeurs individuelles.
Notez que l'ancien système avait %
Et la classe Template
, où cette dernière vous permet de créer des sous-classes qui ajoutent ou modifient son comportement. Le système de nouveau style a la classe Formatter
pour remplir la même niche.
Python 3 s'est encore éloigné de la dépréciation, vous donnant plutôt un avertissement dans la section printf
- Style String Formatting :
Remarque : Les opérations de formatage décrites ici présentent une variété de bizarreries qui conduisent à un certain nombre d'erreurs courantes (telles que le fait de ne pas afficher correctement les tuples et les dictionnaires). L'utilisation de la nouvelle littéraux de chaîne formatés ou de l'interface
str.format()
permet d'éviter ces erreurs. Ces alternatives fournissent également des approches plus puissantes, flexibles et extensibles pour formater le texte.
Python 3.6 a également ajouté littéraux de chaîne formatés , qui alignent les expressions dans les chaînes de format. Il s'agit de la méthode la plus rapide pour créer des chaînes avec des valeurs interpolées et doit être utilisée à la place de str.format()
partout où vous pouvez utiliser un littéral.
La dernière position de Guido à ce sujet semble être indiquée ici:
PEP 3101: une nouvelle approche de la mise en forme des chaînes
Un nouveau système pour les opérations de formatage de chaînes intégrées remplace l'opérateur de formatage de chaînes%. (Cependant, l'opérateur% est toujours pris en charge; il sera obsolète dans Python 3.1 et supprimé du langage ultérieurement). Lisez PEP 3101 pour obtenir le scoop complet.
Et le PEP3101 lui-même, dont la dernière modification remonte au (vendredi 30 septembre 2011), donc pas de progrès récemment sur celui-là, je suppose.
En regardant les anciens Python et PEP 3101, il y avait une déclaration selon laquelle l'opérateur% serait obsolète et supprimé du langage à l'avenir. Le déclaration suivante était dans les documents Python pour Python 3.0, 3.1 et 3.2:
Comme str.format () est assez nouveau, beaucoup de code Python utilise toujours l'opérateur%. Cependant, comme cet ancien style de formatage sera finalement supprimé du langage, str.format ( ) devrait généralement être utilisé.
Si vous allez dans la même section dans Python 3.3 et 3.4 docs, vous verrez que cette déclaration a été supprimée. Je ne trouve également aucune autre déclaration ailleurs dans le documentation indiquant que l'opérateur sera obsolète ou supprimé de la langue Il est également important de noter que PEP3101 n'a pas été modifié depuis plus de deux ans et demi (ven. 30 sept. 2011).
Mise à jour
PEP461 L'ajout de la mise en forme% aux octets et au tableau d'octets est accepté et doit faire partie de Python 3.5 ou 3.6. C'est un autre signe que l'opérateur% est vivant et actif.