¿Cuál es la forma correcta de formatear un dict de varias líneas en Python?


184

En Python, quiero escribir un dictado de varias líneas en mi código. Hay un par de formas en que uno podría formatearlo. Aquí hay algunos que se me ocurren:

  1. mydict = { "key1": 1,
               "key2": 2,
               "key3": 3, }
  2. mydict = { "key1": 1,
               "key2": 2,
               "key3": 3,
             }
  3. mydict = {
        "key1": 1,
        "key2": 2,
        "key3": 3,
    }

Sé que cualquiera de los anteriores es sintácticamente correcto, pero supongo que hay una sangría preferida y un estilo de salto de línea para los dictados de Python. ¿Qué es?

Nota: Este no es un problema de sintaxis. Todo lo anterior son (hasta donde yo sé) declaraciones válidas de Python y son equivalentes entre sí.


12
Para 1 y 2: No hay espacios directamente dentro de los aparatos ortopédicos, consulte PEP 8.
Sven Marnach

3
Quiero decir que en el módulo python pprint, utiliza su primer ejemplo, sin espacios directamente dentro de los corchetes.
charmoniumQ

Respuestas:


239

Yo uso # 3. Lo mismo para listas largas, tuplas, etc. No requiere agregar espacios adicionales más allá de las sangrías. Como siempre, sea consistente.

mydict = {
    "key1": 1,
    "key2": 2,
    "key3": 3,
}

mylist = [
    (1, 'hello'),
    (2, 'world'),
]

nested = {
    a: [
        (1, 'a'),
        (2, 'b'),
    ],
    b: [
        (3, 'c'),
        (4, 'd'),
    ],
}

Del mismo modo, esta es mi forma preferida de incluir cadenas grandes sin introducir ningún espacio en blanco (como lo haría si usara cadenas de varias líneas con comillas triples):

data = (
    "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABG"
    "l0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAEN"
    "xBRpFYmctaKCfwrBSCrRLuL3iEW6+EEUG8XvIVjYWNgJdhFjIX"
    "rz6pKtPB5e5rmq7tmxk+hqO34e1or0yXTGrj9sXGs1Ib73efh1"
    "AAAABJRU5ErkJggg=="
)

¿Podría incluir alguna referencia? Tengo problemas para encontrar una fuente autorizada sobre esto. (Estoy de acuerdo contigo).
Trufa


66
No se lo digas, pero ese usuario no tiene idea de qué está hablando; P
Trufa

3
jajaja, más en serio, tampoco pude encontrar una referencia "autorizada". ¡Te lo haré saber si lo hago! Quizás alguien debería contactar a Guido.
FogleBird

2
Esto coincide con PEP 8: python.org/dev/peps/pep-0008/#indentation . Hay algunos ejemplos de listas en la parte inferior de la sección sobre sangría.
ams

31

En primer lugar, como dijo Steven Rumbalski, "PEP8 no aborda esta pregunta", por lo que es una cuestión de preferencia personal.

Usaría un formato similar pero no idéntico a su formato 3. Aquí está el mío y por qué.

my_dictionary = { # Don't think dict(...) notation has more readability
    "key1": 1, # Indent by one press of TAB (i.e. 4 spaces)
    "key2": 2, # Same indentation scale as above
    "key3": 3, # Keep this final comma, so that future addition won't show up as 2-lines change in code diff
    } # My favorite: SAME indentation AS ABOVE, to emphasize this bracket is still part of the above code block!
the_next_line_of_code() # Otherwise the previous line would look like the begin of this part of code

bad_example = {
               "foo": "bar", # Don't do this. Unnecessary indentation wastes screen space
               "hello": "world" # Don't do this. Omitting the comma is not good.
} # You see? This line visually "joins" the next line when in a glance
the_next_line_of_code()

btw_this_is_a_function_with_long_name_or_with_lots_of_parameters(
    foo='hello world',  # So I put one parameter per line
    bar=123,  # And yeah, this extra comma here is harmless too;
              # I bet not many people knew/tried this.
              # Oh did I just show you how to write
              # multiple-line inline comment here?
              # Basically, same indentation forms a natural paragraph.
    ) # Indentation here. Same idea as the long dict case.
the_next_line_of_code()

# By the way, now you see how I prefer inline comment to document the very line.
# I think this inline style is more compact.
# Otherwise you will need extra blank line to split the comment and its code from others.

some_normal_code()

# hi this function is blah blah
some_code_need_extra_explanation()

some_normal_code()

Me gusta el comentario en línea. mi primer profesor de programación (ya había estado programando durante años antes) insistió en comentarios en línea, pero nunca explicó de manera efectiva por qué. ahora has explicado una práctica que he usado durante unos 20 años.
Joshua K

Ajá, gracias. Tenemos edad, experiencia y "kilometraje" similares en términos de programación. Entonces, si ya comenzó esa práctica de comentarios en línea hace 20 años (¡lo cual es impresionante!), ¿Por qué aún necesita la explicación de su profesor sobre eso presumiblemente hace 10 años cuando estaba en su universidad? Sólo curioso. :-)
RayLuo

muy buena pregunta :) ATARI BASIC y GWbasic prácticamente lo forzaron, siendo compiladores basados ​​en líneas de flujo de arriba hacia abajo. Es algo que adopté mientras leía el BASIC de Peter Norton (y luego el código ASM) en revistas en papel. Aprendí Turbo Pascal en el medio, pero ya había aprendido de los ejemplos en las revistas en papel y me ajustaba a las limitaciones de BASIC.
Joshua K

PEP8 lo aborda de alguna manera, ya que recomienda no agregar un espacio inmediatamente después de una llave de apertura, por lo que las opciones 1 y 2 en OP están desactivadas.
Daniel Serodio

9

Dado que sus claves son cadenas y estamos hablando de legibilidad, prefiero:

mydict = dict(
    key1 = 1,
    key2 = 2,
    key3 = 3,
)

66
Prefiero no usar espacios al definir kwargs. c = function(a=1, b=2)Es más "pitónico".
Steve K


0
dict(rank = int(lst[0]),
                grade = str(lst[1]),
                channel=str(lst[2])),
                videos = float(lst[3].replace(",", " ")),
                subscribers = float(lst[4].replace(",", "")),
                views = float(lst[5].replace(",", "")))

Esto no responde la pregunta
bagerard

-1

Desde mi experiencia con los tutoriales y otras cosas, el número 2 siempre parece preferible, pero es una opción de preferencia personal más que cualquier otra cosa.


-6

En general, no incluiría la coma después de la entrada final, pero Python lo corregirá por usted.


34
¡No! Incluya siempre la coma final, de modo que si agrega un nuevo último elemento, no tiene que cambiar la línea antes. Esta es una de las mejores cosas de Python: practicidad sobre pureza.
Ned Batchelder

2
Además, esta respuesta no aborda la pregunta formulada.
RKD314
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.