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

6 minutos de lectura

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 asumo que hay un estilo preferido de sangría y salto de línea para los dictados de Python. ¿Qué es?

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

  • Para 1 y 2: No hay espacios directamente dentro de las llaves, consulte PEP 8.

    – Sven Marnach

    17 de junio de 2011 a las 15:41

  • Quiero decir que en el módulo pprint de Python, usa su primer ejemplo, sin espacios directamente dentro de las llaves.

    – charmoniumQ

    6 de enero de 2013 a las 15:49

avatar de usuario
FogleBird

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

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 entre 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

    17 de junio de 2011 a las 16:34

  • No le digas pero ese usuario no tiene idea de lo que habla ;P

    – Trufa

    17 de junio de 2011 a las 18:43

  • lol, más en serio, tampoco pude encontrar una referencia “autorizada”. ¡Te avisaré si lo hago! Quizás alguien debería contactar a Guido.

    – FogleBird

    17/06/2011 a las 19:00

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

    – Aarón Cisne

    15 de junio de 2018 a las 20:52

  • Su ejemplo “anidado” es una sintaxis no válida.

    – datos

    5 de febrero de 2020 a las 14:30

avatar de usuario
RayLuo

En primer lugar, como dijo Steven Rumbalski, “PEP8 no aborda esta cuestión”, 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) insistió en los comentarios en línea, pero nunca explicó por qué. Ahora ha explicado una práctica que he usado durante unos 20 años.

    – Josué K.

    20 de abril de 2013 a las 1:50

  • 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é todavía necesitaba la explicación de su profesor presumiblemente hace 10 años cuando estaba en su universidad? Sólo curioso. 🙂

    – Ray Luo

    20 de abril de 2013 a las 3:32

  • 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é cuando leí el BASIC de Peter Norton (y más tarde el código ASM) en revistas impresas. aprendí Turbo Pascal en el medio, pero ya había aprendido de los ejemplos en las revistas impresas y me ajusté a las limitaciones de BASIC.

    – Josué K.

    26 de abril de 2013 a las 13:15

  • 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 descartadas.

    –Daniel Serodio

    01/04/2014 a las 17:41

avatar de usuario
dugres

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

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

  • Prefiero no usar espacios al definir kwargs. c = function(a=1, b=2) es más “pitónico”.

    – Steve K.

    22 de julio de 2014 a las 14:42

Por lo general, si tiene objetos Python grandes, es bastante difícil formatearlos. Personalmente, prefiero usar algunas herramientas para eso.

Aquí está python-beautifier – www.cleancss.com/python-beautify que convierte instantáneamente sus datos en un estilo personalizable.

flake8: una utilidad para hacer cumplir la coherencia de estilo en el código python, que verifica la sintaxis de su código y brinda instrucciones para mejorarlo; recomienda este formato (consulte https://www.flake8rules.com/rules/E133.html):

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

  • Sin embargo, parece que esta verificación no está activada de forma predeterminada. Parece que PEP 8 (vinculado desde flake8) especifica este o mi estilo 3 de la pregunta como alternativas aceptables. ¿Tiene alguna idea de por qué este debe ser preferido sobre el otro?

    – Ryan C. Thompson

    6 de febrero a las 17:24

  • Dice “Mejor práctica”, por razones, lea la respuesta de RayLuo, línea de código 5 y 6.

    – mowsy

    6 de febrero a las 20:03


avatar de usuario
jake

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

  • Sin embargo, parece que esta verificación no está activada de forma predeterminada. Parece que PEP 8 (vinculado desde flake8) especifica este o mi estilo 3 de la pregunta como alternativas aceptables. ¿Tiene alguna idea de por qué este debe ser preferido sobre el otro?

    – Ryan C. Thompson

    6 de febrero a las 17:24

  • Dice “Mejor práctica”, por razones, lea la respuesta de RayLuo, línea de código 5 y 6.

    – mowsy

    6 de febrero a las 20:03


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

    10 de febrero de 2020 a las 22:13

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad