101 votes

Importation de modules Python : Ligne unique ou lignes multiples

Lors de l'importation de modules en Python, quelle est la différence entre ceci :

from module import a, b, c, d

et ceci

from module import a
from module import b
from module import c
from module import d

Pour moi, il est logique de toujours condenser le code et d'utiliser le premier exemple, mais j'ai vu des exemples de code faire le second. Y a-t-il une différence ou est-ce que tout est dans la préférence du programmeur ?

142voto

inspectorG4dget Points 25092

Il n'y a pas de différence du tout. Ils fonctionnent tous les deux exactement de la même manière.

Toutefois, d'un point de vue stylistique, l'un peut être préférable à l'autre. Et sur cette note, le PEP-8 pour les importations dit que vous devriez compresser from module import name1, name2 sur une seule ligne et laissez import module1 sur plusieurs lignes :

Yes: import os
     import sys

No:  import sys, os

Ok: from subprocess import Popen, PIPE

En réponse au commentaire de @teewuane (répété ici au cas où le commentaire serait supprimé) :

@inspectorG4dget Et si vous deviez importer du matériel module et que cela finit par rendre la ligne plus longue que 80 caractères ? Je sais que Je sais que la règle des 80 caractères est "quand cela rend le code plus lisible" mais je me mais je me demande toujours s'il n'y a pas une façon plus ordonnée de faire cela. Et je ne veux pas Et je ne veux pas faire from foo import * alors que je suis en train d'importer tout.

Le problème est qu'en faisant quelque chose comme ce qui suit, on risque de dépasser la limite des 80 caractères :

from module import func1, func2, func3, func4, func5

A cela, j'ai deux réponses (je ne vois pas que PEP8 soit trop clair à ce sujet) :

Divisez-le en deux importations :

from module import func1, func2, func3
from module import func4, func5

Cela présente l'inconvénient que si module est supprimé de la base de code ou autrement remanié, alors les deux lignes d'importation devront être supprimées. Cela pourrait s'avérer douloureux

Diviser la ligne :

Pour atténuer le problème ci-dessus, il peut être plus sage de faire

from module import func1, func2, func3, \
     func4, func5

Il en résulterait une erreur si la deuxième ligne n'est pas supprimée en même temps que la première, tout en conservant l'instruction d'importation singulière

56voto

Jacob Powers Points 541

Pour ajouter à certaines des questions soulevées par Réponse de l'inspecteurG4dget Vous pouvez également utiliser des tuples pour effectuer des importations multi-lignes lorsque les structures de dossiers commencent à être profondément imbriquées ou lorsque vous avez des modules avec des noms obtus.

from some.module.submodule.that_has_long_names import (
    first_item,
    second_item,
    more_imported_items_with_really_enormously_long_names_that_might_be_too_descriptive,
    that_would_certainly_not_fit,
    on_one_line,
)

Cela fonctionne aussi, bien que je ne sois pas un fan de ce style :

from module import (a_ton, of, modules, that_seem, to_keep, needing,
                    to_be, added, to_the_list, of_required_items)

16voto

ShitalShah Points 2213

Je vous conseille de ne pas suivre aveuglément le PEP-8. Lorsque vous avez environ la moitié d'un écran d'importations, les choses commencent à devenir inconfortables et PEP-8 est alors en conflit avec les directives de lisibilité de PEP-20.

Ma préférence est,

  1. Mettez tous les imports intégrés sur une ligne comme sys, os, time etc.
  2. Pour les autres importations, utilisez une ligne par paquet (pas par module)

Ce qui précède vous donne un bon équilibre car le lecteur peut toujours jeter un coup d'œil rapide sur les dépendances tout en obtenant une compacité raisonnable.

Par exemple,

Ma préférence

# one line per package

import os, json, time, sys, math
import numpy as np
import torch, torch.nn as nn, torch.autograd, torch.nn.functional as F
from torchvision models, transforms

Recommandation PEP-8

# one line per module or from ... import statement

import os
import json
import time
import sys
import math

import numpy as np

import torch
from torch import nn as nn, autograd, nn.functional as F
from torchvision import models, transforms

8voto

Une préoccupation non mentionnée par les autres réponses est celle des conflits de fusion git.

Disons que vous commencez avec cette déclaration d'importation :

import os

Si vous changez cette ligne en import os, sys dans une branche et import json, os dans une autre branche, vous obtiendrez ce conflit lorsque vous tenterez de les fusionner :

<<<<<<< HEAD
import os, sys
=======
import json, os
>>>>>>> branch

Mais si vous ajoutez import sys y import json sur des lignes séparées, vous obtenez un beau commit de fusion sans conflits :

--- a/foo.py
+++ b/foo.py
@@@ -1,2 -1,2 +1,3 @@@
+ import json
  import os
 +import sys

Vous obtiendrez toujours un conflit si les deux importations ont été ajoutées au même endroit, car git ne sait pas dans quel ordre elles doivent apparaître. Ainsi, si vous aviez importé time au lieu de json par exemple :

import os
<<<<<<< HEAD
import sys
=======
import time
>>>>>>> branch

Néanmoins, il peut être intéressant de s'en tenir à ce style pour les occasions où il permet d'éviter les conflits de fusion.

2voto

pythonboi Points 11

Les importations doivent généralement être sur des lignes séparées, conformément aux directives PEP 8.

# Wrong Use
import os, sys
# Correct Use
import os
import sys

Pour plus de violations et de corrections de la PEP 8 basées sur l'importation, veuillez consulter le site suivant https://ayush-raj-blogs.hashnode.dev/making-clean-pr-for-open-source-contributors-pep-8-style .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X