Existe-t-il un format recommandé pour les importations multilignes?

114

J'ai lu qu'il y a trois façons de coder les importations multilignes en python

Avec des barres obliques:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text, \
    LEFT, DISABLED, NORMAL, RIDGE, END

Duplication des senteces:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END

Avec parenthèses:

from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

Existe-t-il un format recommandé ou une manière plus élégante pour ces déclarations?

python python-2.7 pep8

— Manuel Alvarez
source

3

avec autant d'importations, pourquoi pas simplement from Tkinter import *?

— Inbar Rose

2

Ceci est un exemple. La vraie déclaration est from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ WebEmbeddedFieldmais ne veut pas importer tout le reste des champs incorporés dans data.forms

— Manuel Alvarez

19

De nombreuses raisons. Par exemple, vous pourriez écraser de nombreuses variables dont vous n'avez pas connaissance. Connaissez-vous tous les noms importés par from Tkinter import *? Je ne suis pas. Et les IDE ne sauront pas si ces noms (peut-être), ils ne peuvent donc pas dire si vous avez entré un nom invalide.

— Thorsten Kranz

2

@InbarRose C'est une mauvaise habitude, regardez stackoverflow.com/questions/3615125/...

— Yuval Pruss

161

Personnellement, je vais avec des parenthèses lors de l'importation de plus d'un composant et les trie par ordre alphabétique. Ainsi:

from Tkinter import (
    Button,
    Canvas,
    DISABLED,
    END,
    Entry,
    Frame,
    LEFT,
    NORMAL,
    RIDGE,
    Text,
    Tk,
)

Cela a l'avantage supplémentaire de voir facilement quels composants ont été ajoutés / supprimés dans chaque commit ou PR.

Dans l'ensemble, c'est une préférence personnelle et je vous conseillerais de choisir ce qui vous convient le mieux.

— Brendan Maguire
source

3

Je pense que l'important est d'être cohérent (du moins au sein d'un projet donné). Cela permettra à quelqu'un qui lit le code de trouver facilement ce qui est importé sans trop de difficultés.

— Blckknght

1

isort peut être utilisé pour formater automatiquement les importations multilignes dans différents styles, voir github.com/timothycrosley/isort#multi-line-output-modes

— Motin

16

Vos exemples semblent provenir de la PEP 328 . Là, la notation entre parenthèses est proposée pour exactement ce problème, donc je choisirais probablement celui-ci.

— Thorsten Kranz
source

4

J'irais avec la notation entre parenthèses du PEP328 avec des nouvelles lignes ajoutées avant et après les parenthèses:

from Tkinter import (
    Tk, Frame, Button, Entry, Canvas, Text, 
    LEFT, DISABLED, NORMAL, RIDGE, END
)

C'est le format que Django utilise:

from django.test.client import Client, RequestFactory
from django.test.testcases import (
    LiveServerTestCase, SimpleTestCase, TestCase, TransactionTestCase,
    skipIfDBFeature, skipUnlessAnyDBFeature, skipUnlessDBFeature,
)
from django.test.utils import (
    ignore_warnings, modify_settings, override_settings,
    override_system_checks, tag,
)

— Max Malysh
source

Il n'y a pas de nouvelles lignes ajoutées après / avant la parenthèse dans PEP 328?

— Gandalf Saxe

@GandalfSaxe PEP 328 concernait la sémantique (ajout d'une nouvelle fonctionnalité au langage), pas le formatage.

— Max Malysh

Je ne comprends donc pas très bien. Vous citez PEP 328 comme ayant des parenthèses pour les importations multilignes, mais elles n'en ont aucune? "J'irais avec la notation entre parenthèses du PEP328 avec des nouvelles lignes ajoutées avant et après les parenthèses:"

— Gandalf Saxe

PEP 328 a ajouté la notation entre parenthèses à la langue. La notation est la capacité Parenthesis importer plusieurs modules comme ceci: from foo import (bar, baz). PEP 328 ne dit rien sur le formatage.

— Max Malysh

Ah ok, je vois ce que tu veux dire maintenant :)

— Gandalf Saxe

-4

Habituellement, avec Tkinter, il est acceptable de simplement l'utiliser from Tkinter import *car le module n'exportera que les noms qui sont clairement des widgets.

PEP 8 ne répertorie aucune convention pour un tel cas, donc je suppose que c'est à vous de décider quelle est la meilleure option. Tout est question de lisibilité, alors choisissez ce qui indique clairement que vous importez des éléments à partir d'un seul module.

Comme tous ces noms sont disponibles dans votre champ d'application, je pense personnellement que les options 2 sont les plus claires car vous pouvez voir les noms importés les meilleurs. Vous pourriez même le diviser davantage pour peut-être regrouper ces noms qui vont les uns avec les autres. Dans votre exemple, je pourrais mettre Tk, Frameet Canvasséparément, car ils regroupent les widgets ensemble, tout en ayant Buttonet Textséparément car ils sont des composants plus petits dans une vue.

— poussée
source

11

Il n'est jamais permis d'utiliser à partir de l'importation X *

— Tolo Palmer

1

@ToloPalmer Habituellement, c'est vrai, mais pour Tkinter c'est généralement correct, car vous importez uniquement des widgets; il est même répertorié de cette façon dans la référence de la bibliothèque . Et si vous indiquez l'importation comme la première, vous devez être particulièrement à l'abri de tout conflit.

— poke le

1

Pour référence, le problème from X import *même pour les packages qui utilisent __all__correctement est que les analyseurs de code statiques comme pyflakesne peuvent pas détecter les noms non définis s'il y en a, import *car ils doivent supposer que tous les noms non définis ont peut-être été importés par le *.

— RubenLaguna