Недостаток каждой формы
При чтении чужого кода (и эти люди используют очень разные стили импорта), я заметил следующие проблемы с каждым из стилей:
import modulewithaverylongname
будет загромождать код далее длинным именем модуля (например, concurrent.futures
или django.contrib.auth.backends
) и уменьшать читабельность в этих местах.
from module import *
дает мненет никакой возможности синтаксически увидеть, что, например, classA
и classB
происходят из одного модуля и имеют много общего друг с другом.Это делает чтение кода сложным .(То, что имена из такого импорта могут скрывать имена из более раннего импорта, является наименьшей частью этой проблемы.)
from module import classA, classB, functionC, constantD, functionE
перегружает мою кратковременную память слишком большим количеством имен, которые ямысленно нужно присвоить module
, чтобы связно понять код.
import modulewithaverylongname as mwvln
иногда недостаточно мнемоничен для me .
Подходящий компромисс
Основываясь на вышеприведенных наблюдениях, я разработал следующий стиль в своем собственном коде:
import module
является предпочтительным стилем, если имя модулякороче как например большинство пакетов в стандартной библиотеке.Это также предпочтительный стиль, если мне нужно использовать имена из модуля только в двух или трех местах в моем собственном модуле;тогда ясность важнее краткости ( «Читаемость имеет значение» ).
import longername as ln
- предпочтительный стиль почти во всех других случаях.Например, я мог бы import django.contrib.auth.backends as dj_abe
.По приведенному выше определению критерия 1 аббревиатура будет использоваться часто, и поэтому ее достаточно легко запомнить.
Только эти два стиля являются полностью питоническими согласно «Явное лучше, чем неявное." rule.
from module import xx
все еще иногда встречается в моем коде.Я использую его в случаях, когда даже формат as
выглядит преувеличенным, самый известный пример - from datetime import datetime
.