web-dev-qa-db-fra.com

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

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

Entre 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?

101
Manuel Alvarez

Personnellement, j'utilise des parenthèses lors de l'importation de plusieurs composants et je 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 conseille de choisir ce qui vous convient le mieux.

137
Brendan Maguire

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

14
Thorsten Kranz

J'irais avec la notation entre parenthèses du PEP328 avec des retours à la ligne ajoutés 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,
)
3
Max Malysh