Les guillemets simples contre les guillemets doubles en Python [fermé]


718

Selon la documentation, ils sont à peu près interchangeables. Y a-t-il une raison stylistique à utiliser l'un sur l'autre?

Réponses:


525

J'aime utiliser des guillemets doubles autour des chaînes qui sont utilisées pour l'interpolation ou qui sont des messages en langage naturel, et des guillemets simples pour les petites chaînes de type symbole, mais enfreindront les règles si les chaînes contiennent des guillemets, ou si j'oublie. J'utilise des guillemets triples pour les docstrings et les littéraux de chaînes brutes pour les expressions régulières même si elles ne sont pas nécessaires.

Par exemple:

LIGHT_MESSAGES = {
    'English': "There are %(number_of_lights)s lights.",
    'Pirate':  "Arr! Thar be %(number_of_lights)s lights."
}

def lights_message(language, number_of_lights):
    """Return a language-appropriate string reporting the light count."""
    return LIGHT_MESSAGES[language] % locals()

def is_pirate(message):
    """Return True if the given message sounds piratical."""
    return re.search(r"(?i)(arr|avast|yohoho)!", message) is not None

4
Intéressant, je les utilise exactement de la même manière. Je ne me souviens pas avoir lu quoi que ce soit pour me pousser dans cette direction. J'utilise également des guillemets simples triples pour les chaînes longues non destinées aux humains, comme le HTML brut. C'est peut-être quelque chose à voir avec les règles de devis en anglais.
Mike A

12
La plupart des codeurs python le codent de cette façon. Il n'y a pas de règle explicite, mais parce que nous lisons souvent le code de cette façon, cela devient une habitude.
e-satis

Je me demande si les guillemets simples pour les choses semblables à des symboles proviennent réellement du raccourci d'expression de citation dans Lisp / Scheme. En tout cas, c'est intuitif. De plus, mes amis, si nous suivons les directives de style PEP 8, les fonctions devraient vraiment être nommées lights_message () et is_pirate ().
yukondude

8
Je pense que Perl a fait une distinction entre les chaînes entre guillemets simples (pas d'interpolation) et les chaînes entre guillemets doubles (avec interpolation) et que les codeurs python peuvent avoir hérité de l'habitude ou ne jamais la laisser partir.
Daren Thomas

2
J'utilise la même convention, et j'en abuse en faisant en sorte que vim surligne tout dans les guillemets simples triples comme SQL.
RoundTower

96

Citant les documents officiels sur https://docs.python.org/2.0/ref/strings.html :

En clair: les littéraux de chaîne peuvent être placés entre guillemets simples (') ou doubles (").

Il n'y a donc aucune différence. Au lieu de cela, les gens vous diront de choisir le style qui correspond au contexte et d'être cohérent . Et je serais d'accord - ajoutant qu'il est inutile d'essayer de trouver des "conventions" pour ce genre de chose parce que vous finirez par confondre les nouveaux arrivants.


3
oui, pour moi, la cohérence est la clé, donc j'utilise des singles partout. Moins de touches, sans ambiguïté et cohérentes.
mlissner

90

J'avais l'habitude de préférer ', surtout pour '''docstrings''', comme je trouve """this creates some fluff""". Aussi, 'peut être tapé sans la Shifttouche sur mon clavier suisse allemand.

J'ai depuis changé pour utiliser des guillemets triples pour """docstrings""", pour me conformer au PEP 257 .


2
J'ai tendance à préférer les guillemets simples, car j'écris du code SQL tous les jours, et les guillemets simples sont utilisés pour les littéraux de chaîne dans T-SQL. Mais j'utilise des guillemets triples, car les docstrings peuvent parfois utiliser un peu de duvet.
eksortso

4
Utiliser partout des guillemets simples pour les chaînes me permet de désactiver des parties du code source en utilisant trois guillemets doubles - une sorte de "#if 0" et "#endif".
dim

12
"nécessite une touche Maj uniquement sur un clavier PC QWERTY. Sur mon clavier, "c'est en fait plus facile à taper.
e-satis

6
sur mon clavier "et" les deux nécessitent la touche Maj.
Loïc Faure-Lacroix

10
Cette réponse est contraire à la convention python; voir PEP 257 qui dit: Pour des raisons de cohérence, utilisez toujours "" "des guillemets doubles" "" autour des docstrings. python.org/dev/peps/pep-0257
Buttons840

44

Je suis avec Will:

  • Citations doubles pour le texte
  • Des guillemets simples pour tout ce qui se comporte comme un identifiant
  • Littéraux de chaîne brute entre guillemets doubles pour les expressions rationnelles
  • Triples citations doubles pour les docstrings

Je m'en tiendrai à cela même si cela signifie beaucoup d'évasion.

J'obtiens le plus de valeur des identificateurs simples entre guillemets qui se distinguent à cause des citations. Le reste des pratiques est là juste pour donner à ces identifiants cités un peu de place.


26

Si la chaîne que vous avez en contient une, vous devez utiliser l'autre. Par exemple "You're able to do this", ou'He said "Hi!"' . En dehors de cela, vous devez simplement être aussi cohérent que possible (au sein d'un module, au sein d'un package, au sein d'un projet, au sein d'une organisation).

Si votre code va être lu par des personnes qui travaillent avec C / C ++ (ou si vous basculez entre ces langages et Python), alors utilisez ''pour des chaînes de caractères uniques, et"" de chaînes plus longues peut aider à faciliter la transition. (De même pour suivre d'autres langues où elles ne sont pas interchangeables).

Le code Python Je l' ai vu dans la nature tend à favoriser "plus ', mais seulement un peu. La seule exception est qu'ils """these"""sont beaucoup plus courants que '''these''', d'après ce que j'ai vu.


21

Les commentaires triples sont un sous-sujet intéressant de cette question. PEP 257 spécifie des guillemets triples pour les chaînes de doc . J'ai fait une vérification rapide en utilisant Google Code Search et j'ai constaté que les doubles guillemets doubles en Python sont environ 10 fois plus populaires que les guillemets simples triples - 1,3 M contre 131 000 occurrences dans le code Google indexes. Donc, dans le cas de plusieurs lignes, votre code sera probablement plus familier aux gens s'il utilise des guillemets doubles.


13
"If you're going to use apostrophes, 
       ^

you'll definitely want to use double quotes".
   ^

Pour cette simple raison, j'utilise toujours des guillemets doubles à l'extérieur. Toujours

En parlant de peluches, à quoi sert de rationaliser vos littéraux de chaîne avec 'si vous devez utiliser des caractères d'échappement pour représenter des apostrophes? Cela choque-t-il les codeurs de lire des romans? Je ne peux pas imaginer à quel point les cours d'anglais au lycée étaient douloureux pour vous!


11
«Si vous allez« citer »quelque chose, vous voudrez certainement utiliser des guillemets simples»
Paolo

Mon opinion a beaucoup changé depuis que j'ai écrit ceci. C'est maintenant une sorte de situation où je dirais que j'utiliserais des guillemets doubles. Un autre serait le vôtre dans le contexte de l'utilisation de guillemets simples. Voir la réponse acceptée pour ma position actuelle sur la question plus en détail. Je pense que c'est un excellent exemple de la façon dont il devrait être présenté à un large public.
Droogans

7

Python utilise des guillemets comme ceci:

mystringliteral1="this is a string with 'quotes'"
mystringliteral2='this is a string with "quotes"'
mystringliteral3="""this is a string with "quotes" and more 'quotes'"""
mystringliteral4='''this is a string with 'quotes' and more "quotes"'''
mystringliteral5='this is a string with \"quotes\"'
mystringliteral6='this is a string with \042quotes\042'
mystringliteral6='this is a string with \047quotes\047'

print mystringliteral1
print mystringliteral2
print mystringliteral3
print mystringliteral4
print mystringliteral5
print mystringliteral6

Ce qui donne la sortie suivante:

this is a string with 'quotes'
this is a string with "quotes"
this is a string with "quotes" and more 'quotes'
this is a string with 'quotes' and more "quotes"
this is a string with "quotes"
this is a string with 'quotes'

2
Mais """This is a string with "quotes""""déclenche une SyntaxError. Comment résoudre cette situation? (idem qu'avec '''This is a string with 'quotes'''')
dolma33

1
Insérer un saut de ligne entre "guillemets" et "" "
Nicolas

1
@ dolma33 La suggestion de Nicolas changerait le contenu de la chaîne. Une meilleure solution est déjà dans la réponse: si votre chaîne se termine par une sorte de citation, utilisez l' autre type de citation triple. Par exemple, '''This is a string with "quotes"'''.
jpmc26

3

J'utilise des guillemets doubles en général, mais pas pour une raison spécifique - Probablement juste par habitude de Java.

Je suppose que vous êtes également plus susceptible de vouloir des apostrophes dans une chaîne littérale en ligne que de vouloir des guillemets doubles.


3

Personnellement, je reste avec l'un ou l'autre. Ça n'a pas d'importance. Et donner votre propre sens à l'une ou l'autre des citations revient à confondre les autres lorsque vous collaborez.


2

C'est probablement une préférence stylistique plus que tout. Je viens de vérifier PEP 8 et je n'ai vu aucune mention de guillemets simples ou doubles.

Je préfère les guillemets simples parce que c'est une seule touche au lieu de deux. Autrement dit, je n'ai pas à écraser la touche Maj pour faire un guillemet simple.


1
PEP 8 établit un lien avec PEP 257 dans la première phrase sous "Documentation Strings". Dans PEP 257, il indique: Pour des raisons de cohérence, utilisez toujours "" "des guillemets doubles" "" autour des chaînes de doc. Utilisez r "" "guillemets doubles bruts" "" si vous utilisez des barres obliques inverses dans vos docstrings. Pour les docstrings Unicode, utilisez u "" "les chaînes entre guillemets Unicode" "". Pourtant, j'aime l'aspect propre des guillemets simples et la seule raison que vous avez donnée.
maxpolk

2

En Perl, vous voulez utiliser des guillemets simples lorsque vous avez une chaîne qui n'a pas besoin d'interpoler des variables ou des caractères d'échappement comme \ n, \ t, \ r, etc.

PHP fait la même distinction que Perl: le contenu entre guillemets simples ne sera pas interprété (même pas \ n sera converti), contrairement aux guillemets doubles qui peuvent contenir des variables pour que leur valeur soit imprimée.

Python ne fonctionne pas, je le crains. Techniquement, il n'y a pas de jeton $ (ou similaire) pour séparer un nom / texte d'une variable en Python. Les deux fonctionnalités rendent Python plus lisible, moins déroutant, après tout. Les guillemets simples et doubles peuvent être utilisés de manière interchangeable en Python.


Pour renforcer ce que vous dites, \ n ne sera interprété qu'en guillemets doubles en PHP et Perl, tandis qu'en Python fonctionnera à la fois en guillemets doubles et simples
Stivlo

1
@stivlo: A moins que vous n'en fassiez une chaîne brute, en ajoutant rdevant la chaîne littérale. Ainsi print 'a\nb', vous imprimerez deux lignes, mais print r'a\nb'vous en imprimerez une.
Tadeck

1

J'ai choisi d'utiliser des guillemets doubles car ils sont plus faciles à voir.


1

J'utilise tout ce qui me plaît à l'époque; il est pratique de pouvoir basculer entre les deux à volonté!

Bien sûr, lorsque vous citez des caractères de devis, le basculement entre les deux n'est peut-être pas si fantaisiste après tout ...


0

Le goût de votre équipe ou les directives de codage de votre projet.

Si vous êtes dans un environnement multilingue, vous souhaiterez peut-être encourager l'utilisation du même type de guillemets pour les chaînes que l'autre langue utilise, par exemple. Sinon, je préfère personnellement le look de '


0

Pour autant que je sache. Bien que si vous regardez du code, "" est couramment utilisé pour les chaînes de texte (je suppose que "est plus courant dans le texte que") et "" apparaît dans les touches de hachage et des choses comme ça.


0

Je vise à minimiser les pixels et la surprise. Je préfère généralement 'afin de minimiser les pixels, mais "plutôt si la chaîne a une apostrophe, encore une fois pour minimiser les pixels. Pour un docstring, cependant, je préfère """plus '''que ce dernier car non standard, peu commun, et donc surprenant. Si maintenant j'ai un tas de chaînes où j'ai utilisé "selon la logique ci-dessus, mais aussi une qui peut s'en tirer avec un ', je peux toujours l'utiliser "pour préserver la cohérence, seulement pour minimiser la surprise.

Peut-être que cela aide à penser à la philosophie de minimisation des pixels de la manière suivante. Préférez-vous que les caractères anglais ressemblent à A B Cou AA BB CC? Ce dernier choix gaspille 50% des pixels non vides.


-1

J'utilise des guillemets doubles parce que je le fais depuis des années dans la plupart des langages (C ++, Java, VB…) sauf Bash, parce que j'utilise également des guillemets doubles dans le texte normal et parce que j'utilise un clavier non anglais (modifié) où les deux caractères nécessitent la touche Maj.


-4

' = "

/= \=\\

exemple :

f = open('c:\word.txt', 'r')
f = open("c:\word.txt", "r")
f = open("c:/word.txt", "r")
f = open("c:\\\word.txt", "r")

Les résultats sont les mêmes

= >> non, ce ne sont pas les mêmes. Une seule barre oblique inversée échappera aux personnages. Vous avez juste de la chance dans cet exemple parce que \ket \wne sont pas des évasions valides comme \tou \nou \\ou\"

Si vous souhaitez utiliser des barres obliques inverses simples (et les faire interpréter comme telles), vous devez utiliser une chaîne "brute". Vous pouvez le faire en mettant un ' r' devant la chaîne

im_raw = r'c:\temp.txt'
non_raw = 'c:\\temp.txt'
another_way = 'c:/temp.txt'

En ce qui concerne les chemins dans Windows, les barres obliques sont interprétées de la même manière. De toute évidence, la chaîne elle-même est différente. Je ne garantirais pas qu'ils soient gérés de cette façon sur un appareil externe.


Putain de merde, c'est vieux, mais je voulais quand même commenter pour souligner que l'utilisation des barres obliques peut fonctionner pour Windows mais dépend toujours du système. Pour vous assurer que vous n'êtes pas dépendant des systèmes d'exploitation, utilisezos.path.join()
Adam Smith
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.