2010-01-13 6 views
103

Comment voulez-vous formater une longue ligne comme celle-ci? Je voudrais l'obtenir à pas plus de 80 caractères de largeur:Comment puis-je rompre cette longue ligne en Python?

logger.info("Skipping {0} because its thumbnail was already in our system as {1}.".format(line[indexes['url']], video.title)) 

Est-ce ma meilleure option?

url = "Skipping {0} because its thumbnail was already in our system as {1}." 
logger.info(url.format(line[indexes['url']], video.title)) 
+1

Cela semble être une bonne option. Qu'est-ce que tu n'aimes pas? –

+2

Un peu subjectif, n'est-ce pas? :) –

+1

related: http://stackoverflow.com/questions/1940710/syntax-quirks-or-why-is-that-valid-python (concaténation de chaînes en python) – jldupont

Répondre

213

C'est un début. Ce n'est pas une mauvaise pratique de définir vos chaînes plus longues en dehors du code qui les utilise. C'est un moyen de séparer les données et le comportement. Votre première option est de rejoindre littéraux de chaîne ainsi implicitement en les rendant adjacents les uns aux autres:

("This is the first line of my text, " 
"which will be joined to a second.") 

Ou avec fin de ligne continuations, ce qui est un peu plus fragile, car cela fonctionne:

"This is the first line of my text, " \ 
"which will be joined to a second." 

Mais ce n'est pas:

"This is the first line of my text, " \ 
"which will be joined to a second." 

Voir la différence? Non? Eh bien, vous ne le ferez pas quand c'est votre code non plus. L'inconvénient de la jointure implicite est qu'elle ne fonctionne qu'avec des littéraux de chaîne, et non avec des chaînes tirées de variables , donc les choses peuvent devenir un peu plus poilues lorsque vous refactorisez. En outre, vous ne pouvez interpoler la mise en forme que sur la chaîne combinée dans son ensemble.

Vous pouvez joindre explicitement en utilisant l'opérateur de concaténation (+):

("This is the first line of my text, " + 
"which will be joined to a second.") 

explicite est mieux que implicite, comme le dit le zen de python, mais cela crée trois chaînes au lieu d'un, et utilise deux fois autant de mémoire: il y a les deux que vous avez écrits, plus un qui est les deux réunis, donc vous devez savoir quand ignorer le zen. L'avantage est que vous pouvez appliquer une mise en forme à l'une des sous-chaînes séparément sur chaque ligne, ou à l'ensemble du lot de l'extérieur des parenthèses.

Enfin, vous pouvez utiliser des chaînes triples guillemets:

"""This is the first line of my text 
which will be joined to a second.""" 

C'est souvent mon préféré, bien que son comportement est légèrement différent comme le saut de ligne et d'éventuels blancs sur les lignes suivantes vont apparaître dans votre chaîne finale . Vous pouvez éliminer le saut de ligne avec une barre oblique inverse qui s'échappe.

"""This is the first line of my text \ 
which will be joined to a second.""" 

Cela a le même problème que la même technique ci-dessus, dans ce code correct ne diffère de code incorrect par un espace invisible.

Lequel est «meilleur» dépend de votre situation particulière, mais la réponse n'est pas simplement esthétique, mais l'un des comportements subtilement différents.

+15

Le compilateur CPython optimise autant que possible les opérations littérales, ce qui signifie que l'ajout de deux littéraux de chaîne n'entraîne qu'un seul littéral de chaîne dans le bytecode. –

+1

Alors que toutes les réponses que j'ai reçues sont utiles, la vôtre m'aide certainement à comprendre toutes les façons de briser les chaînes. Le problème avec la ligne "\" se terminait-il par un espace après? – Gattster

+0

Je ne vois pas la différence ici, mais c'est surtout à cause de la coloration syntaxique plutôt primitive de SO. (Un code parfaitement bon est pratiquement illisible sur SO, mais seulement parce qu'il n'est pas dans une langue dont la syntaxe est très proche de C.) Il n'est pas inhabituel que votre éditeur mette en évidence les espaces, car ils sont rarement utiles (ou intentionnels) . :-) – Ken

27

littéraux de chaîne consécutifs sont rejoints par le compilateur, et les expressions entre parenthèses sont considérées comme une seule ligne de code:

logger.info("Skipping {0} because it's thumbnail was " 
    "already in our system as {1}.".format(line[indexes['url']], 
    video.title)) 
7

Personnellement, je n'aime accrocher des blocs ouverts, donc je formater comme :

logger.info(
    'Skipping {0} because its thumbnail was already in our system as {1}.' 
    .format(line[indexes['url']], video.title) 
) 

En général, je ne m'ennuierais pas trop difficile de faire correspondre le code exactement dans une ligne de 80 colonnes. Il vaut la peine de maintenir la longueur de la ligne à des niveaux raisonnables, mais la limite dure de 80 est une chose du passé.

+6

Ce n'est pas vraiment une chose du passé. La bibliothèque standard Python utilise toujours PEP8 comme guide de style, donc la règle existe toujours, et beaucoup de gens (y compris moi-même) la suivent. C'est un endroit pratique pour tracer la ligne. –

+2

Je me demande combien de projets suivent toujours la règle des 80 chars. Pour la taille de fenêtre moyenne que j'utilise, je pense que 100-120 est plus productif pour moi que 80 caractères. – Gattster

+1

Oui, c'est la longueur de ligne que j'utilise aussi, mais [horreur! sacrilège!] J'utilise une police proportionnelle, donc la longueur de ligne exacte n'est pas si critique. C'est plus un cas de la logique sur une seule ligne qui est lisible que combien de caractères, en tant que tel ... si j'ai une longue chaîne de données que personne n'a besoin de lire, je suis heureux de le laisser déborder 120. – bobince

Questions connexes