Qual è il modo corretto di formattare un dict multilinea in Python?


184

In Python, voglio scrivere un dict multilinea nel mio codice. Ci sono un paio di modi in cui uno potrebbe formattarlo. Eccone alcuni a cui potrei pensare:

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

So che uno dei precedenti è sintatticamente corretto, ma presumo che esista uno stile di rientro e di interruzione di riga preferito per i Dit Python. Che cos'è?

Nota: questo non è un problema di sintassi. Tutte le precedenti sono (per quanto ne so) affermazioni Python valide e sono equivalenti tra loro.


12
Per 1 e 2: nessuno spazio direttamente all'interno delle parentesi graffe, vedere PEP 8.
Sven Marnach,

3
Voglio dire che nel modulo pprint pythons, usa il tuo primo esempio, senza spazi direttamente all'interno delle parentesi graffe.
CharmoniumQ

Risposte:


239

Uso # 3. Lo stesso vale per elenchi lunghi, tuple, ecc. Non richiede l'aggiunta di spazi extra oltre le rientranze. Come sempre, sii coerente.

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

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

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

Allo stesso modo, ecco il mio modo preferito di includere stringhe di grandi dimensioni senza introdurre spazi bianchi (come si otterrebbe se si utilizzassero stringhe a più righe tra virgolette):

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

Potresti includere qualche riferimento, sto avendo problemi a trovare una fonte autorevole su questo. (Sono d'accordo con te).
Trufa,


6
Non dirglielo, ma quell'utente non ha idea di cosa stia parlando; P
Trufa,

3
lol, più seriamente, non sono riuscito a trovare neanche un riferimento "autorevole". Ti farò sapere se lo faccio! Forse qualcuno dovrebbe contattare Guido.
FogleBird,

2
Questo corrisponde a PEP 8: python.org/dev/peps/pep-0008/#indentation . Ci sono alcuni esempi di elenchi nella parte inferiore della sezione sul rientro.
AMS

31

Prima di tutto, come ha detto Steven Rumbalski, "PEP8 non affronta questa domanda", quindi è una questione di preferenze personali.

Vorrei utilizzare un formato simile ma non identico al tuo formato 3. Ecco il mio, e perché.

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()

mi piace il commento in linea. il mio primo professore di programmazione (avevo già programmato per anni prima) ha insistito sui commenti incorporati, ma non ha mai spiegato in modo efficace il perché. ora hai spiegato una pratica che ho usato per circa 20 anni.
Joshua K,

Ah grazie. Abbiamo età, esperienza e "chilometraggio" simili in termini di programmazione. Quindi, se hai già iniziato quella pratica di commenti in linea 20 anni fa (il che è impressionante!), Perché hai ancora bisogno della spiegazione del tuo professore in esso presumibilmente 10 anni fa quando eri nella tua università? Solo curioso. :-)
RayLuo

ottima domanda :) ATARI BASIC e GWbasic l'hanno praticamente costretto, essendo compilatori basati sulla linea di flusso top-down. è qualcosa che ho adottato mentre leggevo BASIC di Peter Norton (e in seguito codice ASM) su riviste cartacee. nel frattempo ho imparato Turbo Pascal, ma avevo già imparato dagli esempi sulle riviste cartacee e mi sono conformato ai limiti di BASIC.
Joshua K,

PEP8 lo risolve in qualche modo poiché raccomanda di non aggiungere uno spazio immediatamente dopo un controvento di apertura, quindi le opzioni 1 e 2 in OP sono fuori.
Daniel Serodio,

9

Poiché le tue chiavi sono stringhe e poiché stiamo parlando di leggibilità, preferisco:

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

6
Preferisci non usare spazi quando definisci kwargs. c = function(a=1, b=2)è più "pythonic".
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(",", "")))

Questo non risponde alla domanda
Bagerard,

-1

Dalla mia esperienza con i tutorial e altre cose il numero 2 sembra sempre preferito, ma è una scelta di preferenza personale più di ogni altra cosa.


-6

Generalmente, non includeresti la virgola dopo la voce finale, ma Python la correggerà per te.


34
No! Includi sempre la virgola finale, quindi se aggiungi un nuovo ultimo elemento, non devi cambiare la linea prima di essa. Questa è una delle grandi cose di Python: praticità sulla purezza.
Ned Batchelder,

2
Inoltre, questa risposta non risponde alla domanda posta.
RKD314,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.