Соглашения об именах пакетов Python

Question

Существует ли соглашение по именованию пакетов для Python, подобное Java com.company.actualpackage? Большую часть времени я вижу простые, потенциально конфликтующие имена пакетов, такие как " web ".

Если такого соглашения нет, есть ли причина для этого? Что вы думаете об использовании соглашения об именах Java в мире Python?

Answer 1

Python имеет две "мантры", которые охватывают эту тему:

Явное лучше, чем неявное.

и

Пространства имен - одна из замечательных идей - давайте сделаем больше таких!

Существует соглашение об именовании и импорте модулей, которое можно найти в Руководство по стилю Python (PEP 8).

Самая большая причина того, что не существует такого соглашения для последовательного добавления префиксов имен ваших модулей в стиле Java, заключается в том, что со временем вы получите много повторений в вашем коде, которые на самом деле не нужны. *

Одна из проблем с Java заключается в том, что она заставляет вас постоянно повторяться. Существует множество шаблонов, которые входят в Java-код, который просто не нужен в Python. (Геттеры / сеттеры являются ярким примером этого.)

Пространства имен не являются большой проблемой в Python, потому что вы можете назначить псевдоним модулям при импорте. Такие как:

import com.company.actualpackage as shortername

Таким образом, вы можете не только создавать или манипулировать пространством имен в своих программах, но и создавать собственные псевдонимы, сохраняющие нажатия клавиш.

Answer 2

Соглашения Java также имеют свои недостатки. Не каждый пакет с открытым исходным кодом имеет стабильный веб-сайт. Что должен сделать сопровождающий, если его сайт изменится? Кроме того, при использовании этой схемы имена пакетов становятся длинными и запоминающимися. Наконец, имя пакета должно представлять цель пакета, а не его владельца

Answer 3

Не существует Java-подобного соглашения об именах для пакетов Python. Конечно, вы можете принять один для любого пакета, который вы разрабатываете самостоятельно, но вам, возможно, придется инвазивно редактировать любой пакет, который вы можете принять от третьих сторон, и «культурно чуждое» соглашение об именах, вероятно, подорвет изменения ваших собственных пакетов, чтобы получить широкое распространение. за пределами вашей организации.

Технически, не было бы ничего плохого в соглашении Java в Python (это просто сделало бы некоторые from заявления немного дольше, ничего страшного), но на практике культурные аспекты делают его практически неосуществимым.

Answer 4

Обновление для всех, кто ищет это:

Начиная с 2012 года, PEP 423 решает эту проблему. PEP 8 кратко затрагивает тему, но только сказать: все строчные или подчеркивания.

Суть этого: выберите запоминающиеся, значимые имена, которые еще не используются в PyPI.

Answer 5

Причина, по которой обычно отсутствует иерархия пакетов, заключается в том, что пакеты Python нелегко расширить таким образом. Пакеты являются фактическими каталогами, и хотя вы можете заставить пакеты искать в нескольких каталогах подмодули (добавляя каталоги в список __path__ пакета), это не удобно, и легко сделать неправильно. Что касается , почему пакеты Python так легко не расширяются, ну, это выбор дизайна. Гвидо не любил глубокие иерархии (и до сих пор не любит) и не считает их необходимыми.

Соглашение состоит в том, чтобы выбрать имя пакета верхнего уровня, которое является очевидным, но уникальным для вашего проекта - например, имя самого проекта. Вы можете структурировать все внутри него так, как вы хотите (потому что вы контролируете его). Разделение пакета на отдельные части с отдельными владельцами - это немного больше работы, но с некоторыми рекомендациями это возможно. Это редко требуется.

Answer 6

Ничто не мешает вам использовать это соглашение, если вы хотите, но это не совсем стандарт в мире Python, и вы, вероятно, получите забавные взгляды. Не очень интересно заботиться об админе для пакетов, когда они глубоко вложены в com.

Это может показаться небрежным для кого-то, пришедшего с Java, но в действительности это, похоже, не вызвало каких-либо больших трудностей, даже с пакетами с таким плохим названием, как web.py.

На практике вы часто делаете конфликты пространства имен на практике - это относительный импорт: где код в package.module1 пытается import module2, и в стандарте есть и 1010 *, и module2 библиотека (которая обычно есть как stdlib, большая и растущая). К счастью, неоднозначный относительный импорт уходит .

Answer 7

Я использую python в течение многих лет, и 99,9% столкновений я видел от новых разработчиков, пытающихся назвать файл "xml.py". Я вижу некоторые преимущества в схеме Java, но большинство разработчиков достаточно умны, чтобы выбирать разумные имена пакетов, так что на самом деле это не такая уж большая проблема.