9
votes

Ajouter des types de conversion personnalisés pour la mise en forme de chaîne

existe-t-il de toute façon à Python pour ajouter des types de conversion supplémentaires au formatage de chaîne?

Les types de conversion standard utilisés dans % -Based chaîne formatage sont des éléments tels que s Strings, d pour les décimales, etc. Ce que je voudrais faire est d'ajouter un nouveau caractère pour lequel je peux spécifier un gestionnaire personnalisé (par exemple une fonction Lambda) qui retournera la chaîne à insertion.

Par exemple, j'aimerais ajouter h en tant que type de conversion pour spécifier que la chaîne doit être échappée à l'aide de HTML. Comme exemple: xxx

et cela utiliserait cgi.escape sur le "titre" pour produire la sortie suivante : xxx


2 commentaires

Vous ne pouvez pas ajouter de nouveau type d'espace réservé au formatage de chaîne, mais vous pouvez toujours déposer vos données d'entrée dans une fonction, qui retournera la sortie souhaitée sous forme de chaîne. '% (titre) S'% {'TITRE ': my_html_formatter (' Preuve que 12 <6 ')}


Merci, je sais. J'ai un groupe de cordes différentes que je vais passer, j'espérais trouver un plus agréable que de les transmettre à une fonction de manière séparément. J'espérais également pouvoir utiliser la même clé (par exemple, «titre») plusieurs fois avec différentes formatage.


3 Réponses :


9
votes

pas avec %% Formatage, non, qui n'est pas extensible.

vous peut spécifier différentes options de formatage lors de l'utilisation du nouveau Syntaxe de chaîne de format défini pour str.cformat () et format () . Les types personnalisés peuvent implémenter un __ format __ () méthode, ce qui sera appelé avec la spécification de format utilisé dans la chaîne de modèle: xxx

Ceci Est-ce que exige que vous utilisiez un type personnalisé pour vos chaînes: xxx

Pour la plupart des cas, il est plus facile de formater la chaîne avant de le remettre au modèle ou utilisez une bibliothèque de modèles HTML dédiée tels que Cameleon, Mako ou Jinja2; Ceux-ci gérent HTML s'échappant pour vous.


4 commentaires

Merci. Je viens de trouver la même solution, mais votre exemple est vraiment utile.


Cette classe n'a pas beaucoup de sens pour moi, vous pouvez simplement dire "{: s}". Format (cgi.escape (titre) ... - exactement ce que l'OP tente d'éviter.


@ THG435: C'est ce que j'adore à la fin de toute façon. Il s'agit principalement d'un exemple de la manière dont vous pouvez accrocher en forme de chaîne avec des spécifications de formatage personnalisées.


@ THG435: Cela offre une petite plus grande flexibilité. Par exemple, je peux utiliser le même format clé à plusieurs reprises avec différents types de formats / de conversion. Il encapsule également l'échappement HTML, donc si je veux faire autre chose que cgi.escape , par exemple, il suffit de le changer à un endroit et de ne pas y penser ailleurs.



17
votes

Vous pouvez créer un formateur personnalisé pour les modèles HTML:

import string, cgi

class Template(string.Formatter):
    def format_field(self, value, spec):
        if spec.endswith('h'):
            value = cgi.escape(value)
            spec = spec[:-1] + 's'
        return super(Template, self).format_field(value, spec)

print Template().format('{0:h} {1:d}', "<hello>", 123)


4 commentaires

Intéressant. J'aime l'idée de ne pas avoir à utiliser des types personnalisés. Je vais donner à la fois un essai de voir ce qui fonctionne mieux avant de choisir une réponse.


J'ai fini par sélectionner cette méthode car il ne s'appuie pas à tout encrasser dans des types personnalisés qui remplacent le format __ . Cependant, vous pouvez également le combiner avec des types personnalisés qui remplacent le format __ sans aucun problème.


Édité pour un traitement plus précis de spécifications.


Remarque Il existe également un Convert_field sur la classe FORMATER , qui gère les conversions de champ de format, comme l'intégré ! S et < code>! r .



4
votes

Je suis un peu en retard à la fête, mais voici ce que je fais, sur la base d'une idée dans https://mail.python.org/pipermail/python-ideas/2011-march/009426.html xxx


0 commentaires