2013-01-17 7 views
69

Znam istnieją trzy sposoby kodowania import kilka linii w PythonieCzy istnieje zalecany format importów wieloliniowych?

Z ukośniki:

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

powielania senteces:

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

W nawiasie:

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

Czy jest zalecany format lub bardziej elegancki sposób do tego oświadczenia?

+3

z tylu importu, to dlaczego nie właśnie 'from Tkinter import *'? –

+2

To jest przykład. Prawdziwe wyrażenie to 'from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ \t WebEmbeddedField' ale nie chcę importować wszystkich pozostałych osadzonych pól w data.forms –

+12

Wiele powodów. Np. Możesz nadpisać wiele zmiennych, których nie znasz. Czy znasz wszystkie nazwy zaimportowane przez 'from Tkinter import *'? Nie jestem. I IDE nie będą wiedzieć, czy te nazwy (być może), a zatem nie będą w stanie stwierdzić, czy wprowadzono nieprawidłowe nazwisko. –

Odpowiedz

89

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

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

Dodatkową zaletą jest łatwe sprawdzenie, które komponenty zostały dodane/usunięte w każdym zatwierdzeniu lub PR.

Ogólnie rzecz biorąc, jest to osobiste preferencje i radzę wybrać wszystko, co wygląda najlepiej.

+2

Myślę, że ważne jest, aby być konsekwentnym (przynajmniej w ramach danego projektu). Ułatwi to komuś odczytanie kodu, aby znaleźć to, co jest importowane bez większych trudności. – Blckknght

+2

Myślę, że brakowało przecinka po "END". Przyjemne podejście, dzięki! – KomodoDave

+4

I, można by się spierać, po 'Tk' – Joost

-2

Zwykle z Tkinter, wystarczy użyć numeru from Tkinter import *, ponieważ moduł będzie eksportować tylko nazwy, które są wyraźnie widżetami.

PEP 8 nie zawiera żadnych konwencji dotyczących takiego przypadku, więc sądzę, że wybór zależy od najlepszej opcji. Wszystko zależy od czytelności, więc wybierz, co wyjaśnia, że ​​importujesz rzeczy z jednego modułu.

Ponieważ wszystkie te nazwy są dostępne w Twoim zasięgu, osobiście uważam, że opcje 2 są najbardziej przejrzyste, ponieważ importowane imiona są najlepsze. Wtedy możesz nawet podzielić go na więcej, aby połączyć te nazwy, które należą do siebie. W twoim przykładzie mogę osobno wstawiać Tk, Frame i Canvas, ponieważ grupują one widgety razem, jednocześnie mając osobne i , ponieważ są one mniejszymi komponentami w widoku.

+5

Nigdy nie można używać X import * –

+0

@ToloPalmer Zwykle to prawda, ale dla Tkintera jest to ogólnie w porządku, ponieważ importowane są tylko widżety; jest nawet wymienione w ten sposób [w bibliografii] (https://docs.python.org/3/library/tkinter.html#tkinter-modules). A jeśli wymienisz import jako pierwszy, powinieneś być szczególnie bezpieczny przed wszelkimi konfliktami. – poke

+1

Dla odniesienia, problem z 'from X import *', nawet dla pakietów, które używają '__all__' poprawnie, to że statyczne analizatory kodu, takie jak' pyflakes', nie mogą wykryć niezdefiniowanych nazw, jeśli istnieje jakikolwiek 'import * ', ponieważ musi on zakładać że jakiekolwiek nieokreślone nazwy mogły zostać zaimportowane przez '*'. – ecerulm

12

Twoje przykłady wydają się pochodzić od PEP 328. Tam właśnie w nawiasie zapisany jest dokładnie ten problem, więc pewnie wybrałbym ten.

1

pójdę z notacją nawiasie z PEP328 z nowymi liniami dodanych przed i po nawiasie:

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

Jest to format, który Django używa:

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, 
) 
Powiązane problemy