2010-01-13 16 views
103

¿Cómo harías para formatear una línea larga como esta? Me gustaría que no tenga más de 80 caracteres de ancho:¿Cómo puedo romper esta larga línea en Python?

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

¿Es esta mi mejor opción?

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

Parece una buena opción. ¿Qué no te gusta de eso? –

+2

Un poco subjetivo, ¿verdad? :) –

+1

relacionado: http://stackoverflow.com/questions/1940710/syntax-quirks-or-why-is-that-valid-python (concatenación de cadena en python) – jldupont

Respuesta

213

Eso es un comienzo. No es una mala práctica definir sus cadenas más largas fuera del código que las usa. Es una forma de separar datos y comportamiento. Su primera opción es unirse a los literales de cadena juntos de manera implícita, haciéndolos adyacentes entre sí:

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

O con el fin de línea continuaciones, que es un poco más frágil, ya que esto funciona:

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

Pero esto no:

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

Ver la diferencia? ¿No? Bueno, no lo harás cuando sea tu código tampoco.

La desventaja de la unión implícita es que solo funciona con cadenas literales, no con cadenas tomadas de variables , por lo que las cosas pueden ponerse un poco más peludas cuando se refactoriza. Además, solo puede interpolar el formato en la cadena combinada como un todo.

Como alternativa, puede unirse de manera explícita usando el operador de concatenación (+):

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

Explícito es mejor que implícito, como el Zen de Python dice, pero esto crea tres cuerdas en vez de uno, y utiliza dos veces tanta memoria: hay dos que has escrito, más uno que son los dos unidos, así que debes saber cuándo ignorar el zen. Lo bueno es que puede aplicar formato a cualquiera de las subcadenas por separado en cada línea, o al lote completo desde fuera de los paréntesis.

Por último, puede utilizar cadenas de triples citado:

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

Esto a menudo es mi favorito, aunque su comportamiento es ligeramente diferente como el salto de línea y espacios en blanco, en las líneas siguientes se mostrarán en su cadena final . Puede eliminar la línea nueva con una barra invertida de escape.

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

Esto tiene el mismo problema que la misma técnica anterior, en el que el código correcta sólo se diferencia de un código incorrecto por espacios en blanco invisible.

Cuál es el "mejor" depende de su situación particular, pero la respuesta no es simplemente estética, sino una de conductas sutilmente diferentes.

+15

El compilador CPython optimiza al máximo las operaciones literales, lo que significa que la adición de dos literales de cadena da como resultado solo un literal de cadena en el bytecode. –

+1

Si bien todas las respuestas que he recibido son útiles, la suya definitivamente me ayuda a comprender todas las formas de romper las cadenas. ¿El problema con la línea "\" terminaba diciendo que había un espacio después? – Gattster

+0

No puedo ver la diferencia aquí, pero eso se debe principalmente a la coloración de sintaxis bastante primitiva de SO. (Algunos códigos perfectamente buenos son prácticamente ilegibles en SO, pero solo porque no están en un lenguaje cuya sintaxis es muy cercana a C.) No es inusual hacer que su editor resalte desalentadoramente los espacios finales, ya que raramente son útiles (o intencionales) . :-) – Ken

27

literales de cadena consecutivos están unidos por el compilador, y las expresiones entre paréntesis se consideran como una sola línea de código:

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

Personalmente me gusta colgar bloques abiertos, así que me gustaría formato como :

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

En general no me molestaría luchar muy duro para hacer que el código ajuste exactamente dentro de una línea de 80 columnas. Vale la pena mantener la longitud de la línea a niveles razonables, pero el límite de los 80 es cosa del pasado.

+6

No es realmente una cosa del pasado. La biblioteca estándar de Python todavía usa PEP8 como su guía de estilo, por lo que la regla todavía existe, y muchas personas (yo incluido) lo siguen. Es un lugar conveniente para trazar la línea. –

+2

Me pregunto cuántos proyectos siguen la regla de los 80 caracteres. Para el tamaño de ventana promedio que uso, creo que 100-120 es más productivo para mí que 80 caracteres. – Gattster

+1

Sí, esa es la longitud de línea que uso también, aunque [¡horror! sacrilegio!] Utilizo una fuente proporcional, por lo que la longitud exacta de la línea no es tan crítica. Es más un caso de cuánta lógica en una sola línea es legible que cuántos caracteres, como tal ... si tengo una larga cadena de datos que nadie necesita leer, me alegra dejar que se extienda 120. – bobince

Cuestiones relacionadas