Czy istnieje zalecany format importu wielu wierszy?


114

Czytałem, że istnieją trzy sposoby kodowania importu wielowierszowego w Pythonie

Z ukośnikami:

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

Powielanie sentencji:

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

Z nawiasami:

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

Czy istnieje zalecany format lub bardziej elegancki sposób na takie stwierdzenia?


3
przy tak wielu importach, dlaczego nie tylko from Tkinter import *?
Inbar Rose

2
To jest przykład. Prawdziwym oświadczeniem jest, from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ WebEmbeddedFieldale nie chcę, importować wszystkich pozostałych pól osadzonych w data.forms
Manuel Alvarez

19
Wiele powodów. Na przykład możesz nadpisać wiele zmiennych, których nie jesteś świadomy. Czy znasz wszystkie nazwiska zaimportowane przez from Tkinter import *? Nie jestem. I IDE nie będą wiedzieć, czy te nazwy (być może), dlatego nie są w stanie stwierdzić, czy wpisałeś nieprawidłową nazwę.
Thorsten Kranz,

2
@InbarRose To zły nawyk, spójrz na stackoverflow.com/questions/3615125/ ...
Yuval Pruss

Odpowiedzi:


161

Osobiście używam nawiasów podczas importowania więcej niż jednego komponentu i sortuję je alfabetycznie. Tak jak to:

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

Ma to dodatkową zaletę polegającą na łatwym sprawdzaniu, jakie komponenty zostały dodane / usunięte w każdym zatwierdzeniu lub żądaniu wykonania.

Ogólnie rzecz biorąc, to osobiste preferencje i radziłbym ci wybrać to, co wygląda najlepiej.


3
Myślę, że ważna jest konsekwencja (przynajmniej w ramach danego projektu). Ułatwi to osobie czytającej kod i bez większych trudności znalezienie tego, co jest importowane.
Blckknght

1
isort może być używany do automatycznego formatowania wielowierszowych importów w różnych stylach, patrz github.com/timothycrosley/isort#multi-line-output-modes
Motin

16

Twoje przykłady wydają się pochodzić z PEP 328 . Tam, właśnie dla tego problemu zaproponowano notację w nawiasach, więc prawdopodobnie wybrałbym ten.


4

Poszedłbym z notacją nawiasów z PEP328 z nowymi wierszami dodanymi przed i po nawiasach:

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

Oto format, którego używa Django :

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

W PEP 328 nie ma nowych linii dodanych po / przed nawiasem?
Gandalf Saxe

@GandalfSaxe PEP 328 dotyczyło semantyki (dodawania nowej funkcji do języka), a nie formatowania.
Max Malysh

Wtedy nie do końca rozumiem. Cytujesz PEP 328 jako nawias dla importu wielowierszowego, ale nie ma żadnego? „Poszedłbym z notacją nawiasów z PEP328 z nowymi wierszami dodanymi przed i po nawiasach:”
Gandalf Saxe

PEP 328 dodał notację w nawiasach do języka. Notacji nawias jest możliwość importowania wielu modułów tak: from foo import (bar, baz). PEP 328 nie mówi nic o formatowaniu.
Max Malysh

Ach ok, teraz rozumiem, co masz na myśli :)
Gandalf Saxe

-4

Zwykle w przypadku Tkintera można go po prostu użyć, from Tkinter import *ponieważ moduł eksportuje tylko nazwy, które są wyraźnie widżetami.

PEP 8 nie wymienia żadnych konwencji dla takiego przypadku, więc myślę, że to do Ciebie należy decyzja, która opcja jest najlepsza. Chodzi o czytelność, więc wybierz to, co sprawia, że ​​jest jasne, że importujesz rzeczy z jednego modułu.

Ponieważ wszystkie te nazwy są dostępne w twoim zakresie, osobiście uważam, że opcja 2 jest najbardziej przejrzysta, ponieważ najlepiej widać importowane nazwy. Możesz nawet podzielić to bardziej, aby być może pogrupować razem te nazwiska, które do siebie pasują. W przykładzie mogę umieścić Tk, Framea Canvasosobno, ponieważ grupa widżety razem, mając jednocześnie Buttoni Textoddzielnie, ponieważ są one mniejsze elementy w widoku.


11
Nigdy nie można używać z X import *
Tolo Palmer

1
@ToloPalmer Zwykle jest to prawda, ale w przypadku Tkinter jest to ogólnie w porządku, ponieważ importujesz tylko widżety; jest nawet wymieniony w ten sposób w odniesieniach do biblioteki . A jeśli wymienisz import jako pierwszy, powinieneś być szczególnie zabezpieczony przed wszelkimi konfliktami.
poke

1
Dla porównania, problem z from X import *nawet pakietami, które używają __all__poprawnie, polega na tym, że statyczne analizatory kodu, takie jak pyflakesnie mogą wykryć niezdefiniowanych nazw, jeśli istnieją, import *ponieważ muszą założyć, że jakiekolwiek niezdefiniowane nazwy mogły zostać zaimportowane przez *.
RubenLaguna,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.