Quelle est la bonne façon de formater un dict multi-lignes en Python?


184

En Python, je veux écrire un dict multi-lignes dans mon code. Il existe plusieurs façons de le formater. En voici quelques-unes auxquelles je pourrais penser:

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

Je sais que tout ce qui précède est syntaxiquement correct, mais je suppose qu'il existe un style d'indentation et de saut de ligne préféré pour les dictionnaires Python. Qu'Est-ce que c'est?

Remarque: ce n'est pas un problème de syntaxe. Tout ce qui précède est (pour autant que je sache) des instructions Python valides et sont équivalentes les unes aux autres.


12
Pour 1 et 2: pas d'espaces directement à l'intérieur des accolades, voir PEP 8.
Sven Marnach

3
Je veux dire que dans le module pythons pprint, il utilise votre premier exemple, sans espaces directement à l'intérieur des accolades.
charmoniumQ

Réponses:


239

J'utilise # 3. Idem pour les longues listes, les tuples, etc. Il ne nécessite pas d'ajouter d'espaces supplémentaires au-delà des indentations. Comme toujours, soyez cohérent.

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

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

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

De même, voici ma façon préférée d'inclure de grandes chaînes sans introduire d'espaces (comme vous le feriez si vous utilisiez des chaînes multilignes triples):

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

Pourriez-vous inclure une référence, j'ai du mal à trouver une source faisant autorité à ce sujet. (Je suis d'accord avec vous).
Trufa

82

6
Ne lui dites pas mais cet utilisateur n'a aucune idée de ce dont il parle; P
Trufa

3
lol, plus sérieusement, je n'ai pas pu trouver une référence "faisant autorité" non plus. Je vous ferai savoir si je le fais! Peut-être que quelqu'un devrait contacter Guido.
FogleBird

2
Cela correspond à PEP 8: python.org/dev/peps/pep-0008/#indentation . Il y a quelques exemples de liste au bas de la section sur l'indentation.
ams le

31

Tout d'abord, comme Steven Rumbalski l'a dit, "PEP8 ne répond pas à cette question", c'est donc une question de préférence personnelle.

J'utiliserais un format similaire mais pas identique à votre format 3. Voici le mien et pourquoi.

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

j'aime le commentaire en ligne. mon premier professeur de programmation (je programmais déjà depuis des années) a insisté sur les commentaires en ligne, mais n'a jamais expliqué pourquoi. vous avez maintenant expliqué une pratique que j'utilise depuis environ 20 ans.
Joshua K

Aha, merci. Nous avons un âge, une expérience et un «kilométrage» similaires en termes de programmation. Donc, si vous avez déjà commencé cette pratique de commentaires en ligne il y a 20 ans (ce qui est impressionnant!), Pourquoi aviez-vous encore besoin des explications de votre professeur il y a probablement 10 ans lorsque vous étiez dans votre université? Juste curieux. :-)
RayLuo

très bonne question :) ATARI BASIC et GWbasic l'ont pratiquement forcé, étant des compilateurs basés sur des lignes de flux descendant. c'est quelque chose que j'ai adopté en lisant le BASIC de peter norton (et plus tard le code ASM) dans les magazines papier. J'ai appris Turbo Pascal entre les deux, mais j'avais déjà appris des exemples dans les magazines papier et je me suis conformé aux limites de BASIC.
Joshua K

PEP8 y remédie quelque peu car il recommande de ne pas ajouter d'espace immédiatement après une accolade ouvrante, donc les options 1 et 2 dans OP sont supprimées.
Daniel Serodio

9

Puisque vos clés sont des chaînes et que nous parlons de lisibilité, je préfère:

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

6
Préférez ne pas utiliser d'espaces lors de la définition des kwargs. c = function(a=1, b=2)est plus "pythonique".
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(",", "")))

Cela ne répond pas à la question
bagerard

-1

D'après mon expérience avec les didacticiels et d'autres choses, le numéro 2 semble toujours préféré, mais c'est un choix de préférence personnelle plus que toute autre chose.


-6

En règle générale, vous n'incluez pas la virgule après l'entrée finale, mais Python corrigera cela pour vous.


34
Non! Incluez toujours la virgule finale, donc si vous ajoutez un nouveau dernier élément, vous n'avez pas à changer la ligne avant. C'est l'une des grandes choses à propos de Python: l'aspect pratique plutôt que la pureté.
Ned Batchelder

2
De plus, cette réponse ne répond pas à la question posée.
RKD314
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.