То, что вы видите здесь, довольно часто (по крайней мере, в некоторых пакетах Python). Если вы определите файл .py
, он будет действовать как модуль. Например, модуль django.views.generic.edit
отображается в файле django/views/generic/edit.py
[GitHub] .
Каталог также является модулем Python (из-за файла __init__.py
), но по умолчанию он не содержит никаких элементов, поэтому это будет означать, что django.views.generic
будет пустым.
Если мы посмотрим на файл django/views/generic/__init__.py
[GitHub] , мы увидим:
from django.views.generic.base import RedirectView, TemplateView, View
# ...
from django.views.generic.edit import (
CreateView, DeleteView, FormView, <b>UpdateView</b>,
)
# ...
__all__ = [
'View', 'TemplateView', 'RedirectView', 'ArchiveIndexView',
'YearArchiveView', 'MonthArchiveView', 'WeekArchiveView', 'DayArchiveView',
'TodayArchiveView', 'DateDetailView', 'DetailView', 'FormView',
'CreateView', <b>'UpdateView'</b>, 'DeleteView', 'ListView', 'GenericViewError',
]
# ...
Таким образом, UpdateView
импортируется из файла generic.py
, а реэкспортирует класс.
Таким образом, вы можете ссылаться на класс двумя способами: через модуль, определенный в файле generic.py
, или через реэкспорт модуля каталога, указанного в файле __init__.py
.
Обычно это делается для экспорта части элементов, определенных в файлах, экспорта их под более удобным именем или предоставления некоторых дополнительных классов на уровне модуля (например, * 1034). * файл определяет ошибку GenericViewError
).
Этот модуль уровня каталогов, таким образом, "группирует" интересные представления вместе. Например, FormMixin
- это , а не , экспортированное на этом уровне. __init__.py
здесь группирует (популярные) представления на основе классов вместе, в то время как миксины, которые обычно используются для определения таких общих представлений, по-прежнему специфичны для файла.