2009-09-16 21 views
5

¿Cuál cree que es la convención que se utiliza principalmente al escribir literales de diccionario en el código?Python bracket convención

Escribiré una posible convención como respuesta.

+3

encuestas deben ser wiki de la comunidad – SilentGhost

Respuesta

16
my_dictionary = { 
    1: 'something', 
    2: 'some other thing', 
} 
+6

1 para la coma final. – RichieHindle

+0

Al principio, no me ha gustado la utilidad de la coma final en las listas, predice, etc. Pero realmente * * simplifica la edición subsiguiente de la lista, si usted está reordenando, copiar/pegar, o la adición de nuevos elementos. – PaulMcG

+3

Agregar una línea es una diferencia de una línea con la coma en su lugar. – u0b34a0f6ae

13

Yo diría que casi no hay estándar.

que he visto dos formas de sangría:

Indent 1: 
my_dictionary = { 
    'uno': 'something', 
    'number two': 'some other thing', 
} 

Indent 2: 
my_dictionary = {'uno': 'something', 
       'number two': 'some other thing', 
       } 

que he visto tres condiciones de tener el soporte final:

End 1: 
my_dictionary = {'uno': 'something', 
       'number two': 'some other thing', 
} 

End 2: 
my_dictionary = {'uno': 'something', 
       'number two': 'some other thing', 
       } 

End 3: 
my_dictionary = {'uno': 'something', 
       'number two': 'some other thing',} 

Y a veces se justifican los valores:

my_dictionary = {'uno':  'something', 
       'number two': 'some other thing', 
       } 

Y a veces incluso los dos puntos:

my_dictionary = {'uno'  : 'something', 
       'number two' : 'some other thing', 
       } 

Lo que se ve raro.

ya veces hay una coma final, ya veces no:

my_dictionary = {'uno': 'something', 
       'number two': 'some other thing'} 

Y a veces se quede todo en una sola fila (si cabe).

my_dictionary = {'uno': 'something', 2: 'some other thing'} 

Todo el mundo parece tener su propia combinación de estos estilos. Personalmente, me inclino por el estilo que usas en tu ejemplo, a menos que haya una razón para no hacerlo. Razones comunes para no hacerlo es cuando tiene un diccionario como parte de una declaración. De esta manera:

amethodthattakesadict({'hey': 'this', 
         'looks': 'a', 
         'bit': 'shitty', 
         }) 

Le recomiendo que se adapte al estilo del tipo que escribió el código que está editando. Si es tu código: haz lo que quieras. :-)

+2

+1 para describir muy bien todas las posibilidades. – hcs42

+5

Creo que la única parte de esos ejemplos realmente gobernados por PEP8 es el espaciado alrededor de los dos puntos. Cero antes, uno después. – Triptych

8

Sobre el refuerzo final: yo prefiero así:

my_dictionary = { 
    'a': 'first value', 
    'b': 'second', 
    } 

y te diré por qué: porque el código Python escotadura tenga ninguna señal cerca, el código está sangría así: el primero line (if, while, def, etc) está superado del resto de la cláusula, con todas las otras líneas sangradas la misma cantidad. La última línea de la cláusula está sangrada junto con todo lo demás. La siguiente línea sangrada igual que la primera línea es la primera línea de la siguiente cláusula, no la última línea de esta.

Me gusta aplicar sangrías a las estructuras de datos usando una convención similar a la de las cláusulas de código, aunque las estructuras de datos tienen un token de cierre explícito, y así podrían tener más flexibilidad.

-3

Puedo hacer esto, si el diccionario es demasiado grande para caber en una sola línea:

d = \ 
    { 
    'a' : 'b', 
    'c' : 'd' 
    } 
3

estilo de sangría 1, terminando estilo 3 (después de la respuesta de Lennart):

my_dictionary = {1: 'thing_one', 
        2: 'thing_two', 
        ... 
        n: 'thing_n'} 

Este podría ser el estilo de sangrado más transparente para las entidades entre corchetes en el código Python, ya que se asemeja mucho espacio en blanco de formato de Python. Bajar a una sangría estilo C en código Python siempre me pareció un poco incómodo, y sospecho que se usa principalmente porque los programadores acostumbrados a los lenguajes tipo C (debido a su ubicuidad) quizás no hayan estado expuestos a diferentes estilos de sangría.

Un inconveniente podría ser que la inserción al principio o al final es un poco más difícil que en otros estilos. Teniendo en cuenta un editor adecuado que admita la escritura de código Python, no debería marcar una gran diferencia.

probar este estilo de sangrado en su contexto, y lo comparan con muesca lateral C-estilo al lado del otro, luego decidir cuál se parece más Pythonic y coherente.

Tal vez esto se podría llamar muesca de estilo Lisp, porque es la forma en que se ha puesto sangría siglos décadas lisp código, pero que es, por ejemplo, también se utiliza a menudo en código Smalltalk. Una cosa que leerá con frecuencia en las discusiones sobre la colocación de paréntesis (en lenguajes tipo Lisp) es: "¿Por qué darles líneas adicionales? ¿Son tan importantes?".

Al final del día, sin embargo, es sobre todo una cosa de gusto.

Cuestiones relacionadas