Python/django, где корень пространства имен?
исходя из php, пространства имен всегда хорошо определены в php, обычно с использованием psr-4 от композитора
https://getcomposer.org/doc/04-schema.md#psr-4
например у тебя есть папка
src/Foo/Bar/Baz
затем вы определяете в файле composer.json, что
src/Foo здесь начинается пространство имен Foo
после этого все подпапки по соглашению являются новым подпространством имен, например.
src/Foo/Bar/Baz/MyClass.php превращается в
Foo.Bar.Baz.MyClass
Скажем, я хочу добавить служебный класс python в свой проект django, который я хочу использовать во всех «приложениях» django.
Куда бы я его бросил и как правильно определить пространство имен? каков прозрачный способ понять пространства имен в python?
@davejagoda, тем не менее, документ psr 4 сбивает с толку (у меня было время, чтобы начать с ним работать), поэтому я создал для вас небольшую суть настоящего composer.json здесь. Примечание: я не заканчиваю папку знаком /, как в документах. Это была ловушка? Я не помню, но это может вам помочь, так что это gist.github.com/Jossnaz/f920231e5018907691621b62a61b0a39
Ответы 2
Из этого документа:
https://docs.djangoproject.com/en/2.2/ref/applications/#projects-and-applications
Это фрагмент:
A project’s root directory (the one that contains manage.py) is usually the container for all of a project’s applications which aren’t installed separately.
Вы можете создать любую выбранную вами иерархию в этом каталоге для утилит, которые могут соответствовать системе package Python:
В Python есть путь поиска модулей. Его можно инициализировать из командной строки с помощью переменной окружения PYTHONPATH и получить программный доступ через sys.path.
По умолчанию каталог сценария, который вы используете для запуска интерпретатора Python, является первой записью в пути поиска.
Любой модуль или пакет на пути python «запускает новое пространство имен», если использовать вашу формулировку. Предположим, что в вашем проекте mysite есть приложение polls со следующей структурой:
mysite
├── manage.py
├── mysite
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ ├── utils.py
│ └── wsgi.py
├── polls
│ ├── __init__.py
│ ├── models.py
│ ├── utils.py
...
Если начать с python manage.py runserver, доступны пакеты mysite и polls.
Я бы сказал, что хорошим местом для модуля utils для всего проекта является пакет проекта mysite. Так что вы делаете import mysite.utils в любом из ваших приложений. Если он выходит за рамки одного файла, вы можете превратить его в подпакет, поэтому вместо utils.py у вас будет utils каталог, содержащий __init__.py файл.
Приведенная выше структура немного загромождает глобальное пространство имен. Поэтому некоторые люди предпочитают структуру, в которой все ваши приложения являются подпакетами пакета вашего проекта, например:
mysite
├── manage.py
├── mysite
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ ├── utils.py
│ ├── wsgi.py
│ └── apps
│ └── polls
│ ├── __init__.py
│ ├── models.py
│ ├── utils.py
...
Спасибо за эту ссылку на psr-4, я подозреваю, что она мне пригодится позже.