W python, jakie są plusy i minusy importowania klasy vs. importowanie modułu klasy?

Question

Jestem autorami zestawu wskazówek kodowania Pythona dla zespołu około 30 programistów. Jako podstawę dla mojego dokumentu, do tej pory studiowałem Google python style guide i PEP 8 style guide i zawarłem informacje z obu.

Jednym z miejsc, w których przewodnik po stylach Google jest bardziej restrykcyjny niż w przypadku artykułu 8, jest import. Przewodnik Google prosi deweloperów tylko o importowanie tylko pakietów i modułów, a następnie odwołaj się do elementów w ramach bardziej kwalifikowanej nazwy. Na przykład:

from pkg import module 
... 
my_class = module.MyClass() 

Uzasadnieniem jest to, że "źródło każdego identyfikatora jest wskazane w spójny sposób". W naszym projekcie zamierzamy organizować z pakietami dwa lub trzy poziomy głębokości, więc aby poznać pełne źródło identyfikatora, czytelnik i tak będzie musiał sprawdzić zgłoszenie importu. Chciałbym popierają ten styl importu jako „preferowanego stylu”:

from pkg.module import MyClass 
... 
my_class = MyClass() 

IMHO, czytelność w konstrukcji Pythona takich jak listowych jest lepsze, gdy nazwy są bardziej zwięzłe.

Nie mam pojęcia, co może zrobić interpreter python za kulisami. Na przykład, czy MyClass jest teraz częścią globalnej przestrzeni nazw dla tego modułu i dla wszystkich importerów tego modułu? (To byłoby złe, mogło prowadzić do dziwnych błędów, gdyby to była prawda, byłbym zwolennikiem stylu Google'a).

Moje doświadczenie w projektowaniu pythonów jest ograniczone do około 6 miesięcy (i nie ma zbyt wielu ekspertów w naszym projekcie do konsultacji), więc chciałem uzyskać więcej informacji od społeczności. Oto niektóre elementy Ja już zbadane:

effbot - discussion on imports

stack overflow - import vs. from import

python documentation - modules

python documentation - import

Dziękuję za odpowiedzi!

Answer 1

W języku Python nie ma czegoś takiego jak zmienna, która jest globalna dla więcej niż jednego modułu. Jeśli wykonasz from pkg.module import MyClass, to MyClass znajduje się w globalnej przestrzeni nazw modułu, w którym to robisz, ale nie w żadnym innym module (w tym modułach, które importują moduł, który importuje MyClass).

Co do bardziej ogólnego pytania, mechanizm importu może być akceptowalny w zależności od sytuacji. Jeśli nazwa modułu jest długa, można uzyskać pewne skrócenie importując go pod inną nazwą:

# Awkward 
from package import reallylongmodule 
reallylongmodule.MyClass() 

# Less awkward 
from package import reallylongmodule as rlm 
rlm.MyClass() 

Importowanie tylko klasa może być w porządku, jeśli nazwa klasy jest na tyle charakterystyczny, że można powiedzieć, skąd przychodzi i co to jest. Jeśli jednak masz wiele modułów definiujących klasy o relatywnie nieopisywalnych nazwach (np. "Procesor", "Jednostka", "Dane", "Menedżer"), dobrym pomysłem może być uzyskanie dostępu do nich za pomocą nazwy modułu w celu wyjaśnienia co robisz.

Przewodniki stylu są ostatecznie przewodnikami, a nie prawami. Moja własna preferencja polegałaby na wybraniu mechanizmu, który maksymalnie zwiększyłby czytelność i czytelność. Wymaga to kompromisu pomiędzy unikaniem długich i uciążliwych nazw, a także unikaniem krótkich, niejasnych lub tajemniczych nazw.Sposób, w jaki dokonujesz tego kompromisu, zależy od konkretnych bibliotek, z których korzystasz i od tego, jak je wykorzystujesz (np. Ile modułów importujesz, ile rzeczy zaimportujesz z nich).

Answer 2

Proponuję użyć automatycznych sprawdzania kodu, takich jak pylint, pep8, pyflakes, zamiast pisać przewodniki kodu.

Ja osobiście wolę używać numeru from pkg import module z powodu możliwych kolizji nazwy.

from package import module 

def my_fun(): 
    module.function() 

Inpreter musi zrobić 3 wyszukiwań hash-table lokalnej przestrzeni nazw funkcji, globalnej przestrzeni nazw bieżącego modułu i przestrzeni nazw importowanego modułu. W

from package.module import function 

def my_fun(): 
    function() 

to zrobić tylko 2 wyszukiwań: ostatni wykonywany w czasie importu.