Comillas simples vs. comillas dobles en Python

Según la documentación, son prácticamente intercambiables. ¿Hay alguna razón estilística para usar una sobre la otra?

Me gusta usar comillas dobles alrededor de cadenas que se usan para la interpolación o que son mensajes en lenguaje natural, y comillas simples para cadenas pequeñas similares a símbolos, pero romperá las reglas si las cadenas contienen comillas, o si las olvido. Uso comillas dobles triples para cadenas de documentación y literales de cadena sin formato para expresiones regulares, incluso si no son necesarias.

Por ejemplo:

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 

Citando los documentos oficiales en https://docs.python.org/2.0/ref/strings.html :

En inglés simple: los literales de cadena pueden incluirse entre comillas simples (‘) o comillas dobles (“).

Así que no hay diferencia. En su lugar, la gente le dirá que elija el estilo que coincida con el contexto y que sea coherente . Y estoy de acuerdo, agregando que no tiene sentido intentar “convenciones” para este tipo de cosas porque solo terminarás confundiendo a los recién llegados.

Solía ​​preferir ' , especialmente para '''docstrings''' , ya que encuentro """this creates some fluff""" . Además, se puede escribir sin la tecla Shift en mi teclado suizo alemán.

Desde entonces he cambiado a usar comillas triples para """docstrings""" , para cumplir con PEP 257 .

Estoy con Will:

  • Doble comillas para texto
  • Comillas simples para cualquier cosa que se comporte como un identificador.
  • Doble citado literales de cadena cruda para expresiones regulares
  • Doble comillas triplicadas para docstrings

Me quedo con eso, incluso si significa escapar mucho.

Aprovecho al máximo el valor de los identificadores de comillas simples que sobresalen debido a las comillas. El rest de las prácticas están ahí solo para dar a esos identificadores citados un poco de espacio.

Si la cadena que tienes contiene una, debes usar la otra. Por ejemplo, "You're able to do this" o 'He said "Hi!"' . Aparte de eso, simplemente debe ser lo más consistente posible (dentro de un módulo, dentro de un paquete, dentro de un proyecto, dentro de una organización).

Si las personas que trabajan con C / C ++ (o si cambia entre esos idiomas y Python) van a leer su código, el uso de '' para cadenas de un solo carácter y "" para cadenas más largas podría ayudar a facilitar la transición. (Igualmente para seguir otros idiomas donde no sean intercambiables).

El código de Python que he visto en la naturaleza tiende a favorecer " sobre ' , pero solo ligeramente. La única excepción es que """these""" son mucho más comunes que '''these''' , por lo que tengo visto

Los comentarios citados triples son un subtema interesante de esta pregunta. PEP 257 especifica comillas triples para cadenas de documentos . Hice una comprobación rápida con Google Code Search y descubrí que las comillas dobles triples en Python son aproximadamente 10 veces más populares que las comillas simples triples : 1.3M contra 131K ocurrencias en el código de los índices de Google. Entonces, en el caso de líneas múltiples, su código probablemente será más familiar para las personas si utiliza comillas dobles triples.

 "If you're going to use apostrophes, ^ you'll definitely want to use double quotes". ^ 

Por esa sencilla razón, siempre uso comillas dobles en el exterior. Siempre

Hablando de pelusa, ¿de qué sirve agilizar sus literales de cuerdas con ‘si va a tener que usar caracteres de escape para representar los apóstrofes? ¿Ofende a los progtwigdores leer novelas? ¡No me puedo imaginar lo dolorosa que fue la clase de inglés de secundaria!

Python usa citas como esta:

 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 

Lo que da el siguiente resultado:

 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' 

Uso comillas dobles en general, pero no por una razón específica, probablemente solo por hábito de Java.

Supongo que también es más probable que desee apóstrofes en una cadena literal en línea que desea comillas dobles.

Personalmente me quedo con uno u otro. No importa. Y proporcionar su propio significado a cualquiera de las citas es simplemente confundir a otras personas cuando colabora.

Probablemente es una preferencia estilística más que nada. Acabo de marcar PEP 8 y ​​no vi ninguna mención de comillas simples o dobles.

Prefiero las comillas simples porque es solo una pulsación de tecla en lugar de dos. Es decir, no tengo que mezclar la tecla de mayúsculas para hacer comillas simples.

En Perl desea usar comillas simples cuando tiene una cadena que no necesita interpolar variables o caracteres escapados como \ n, \ t, \ r, etc.

PHP hace la misma distinción que Perl: el contenido entre comillas simples no se interpretará (ni siquiera se convertirá \ n), a diferencia de las comillas dobles que pueden contener variables para imprimir su valor.

Python no, me temo. Visto técnicamente, no hay $ token (o similar) para separar un nombre / texto de una variable en Python. Ambas características hacen que Python sea más legible, menos confuso, después de todo. Las comillas simples y dobles se pueden usar indistintamente en Python.

Elegí usar comillas dobles porque son más fáciles de ver.

Solo uso lo que sea que me llame la atención en ese momento; ¡Es conveniente poder cambiar entre los dos a su antojo!

Por supuesto, al citar a characetrs, el cambio entre los dos podría no ser tan caprichoso después de todo …

El gusto de su equipo o las pautas de encoding de su proyecto.

Si se encuentra en un entorno multilingüe, es posible que desee fomentar el uso del mismo tipo de comillas para las cadenas que utiliza el otro idioma, por ejemplo. Si no, personalmente me gusta más el look de ‘

Ninguno, que yo sepa. Aunque si miras un código, “” se usa comúnmente para cadenas de texto (supongo que ‘es más común dentro del texto que “), y’ ‘aparece en hashkeys y cosas así.

Mi objective es minimizar tanto los píxeles como la sorpresa. Por lo general, prefiero ' para minimizar los píxeles, pero " cambio si la cadena tiene un apóstrofe, de nuevo para minimizar los píxeles. Sin embargo, para una cadena de documentación, prefiero """ sobre ''' porque este último no es estándar, no es común, Y por lo tanto sorprendente. Si ahora tengo un montón de cadenas en las que usé " según la lógica anterior, pero también una que puede salirse con una ' , aún puedo usar " para preservar la consistencia, solo para minimizar la sorpresa.

Quizás ayude a pensar en la filosofía de minimización de píxeles de la siguiente manera. ¿Prefieres que los caracteres ingleses se vean como ABC o AA BB CC ? La última opción desperdicia el 50% de los píxeles no vacíos.

Uso comillas dobles porque lo he estado haciendo durante años en la mayoría de los idiomas (C ++, Java, VB …) excepto Bash, porque también uso comillas dobles en el texto normal y porque estoy usando un teclado no modificado en inglés donde ambos personajes requieren la tecla shift.

' = "

/ = \ = \\

ejemplo:

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

Los resultados son los mismos

= >> No, no son lo mismo. Una sola barra invertida escapará a los personajes. Simplemente te da suerte en ese ejemplo porque \k \w no son escapes válidos como \t o \n o \\ o \"

Si desea usar barras invertidas únicas (y hacer que se interpreten como tales), entonces necesita usar una cadena “sin procesar”. Puedes hacer esto poniendo una ‘ r ‘ delante de la cuerda

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

En lo que respecta a las rutas en Windows, las barras diagonales se interpretan de la misma manera. Claramente la cadena en sí es diferente aunque. Sin embargo, no garantizaría que se manejen de esta manera en un dispositivo externo.