Есть ли соглашение об именах пакетов для Python, например Java com.company.actualpackage? В большинстве случаев я вижу простые, потенциально конфликтующие имена пакетов, такие как web".
Если такого соглашения нет, есть ли причина для этого? Что вы думаете об использовании соглашения об именах Java в мире Python?
Python имеет две "мантры", которые охватывают эту тему:
Явный лучше, чем неявный.
и
Пространства имен - одна хорошая идея - позвольте сделать больше из них!
Существует соглашение об именах и импорте модулей, которые можно найти в Руководстве по стилю Python (PEP 8).
Самая большая причина, по которой не существует такого соглашения для последовательного префикса имен ваших модулей в стиле Java, заключается в том, что со временем вы получите много повторений в своем коде, который действительно не должен быть там.
Одна из проблем с Java - это заставить вас постоянно повторяться. Там много шаблонов, которые входят в Java-код, который просто не нужен в Python. (Getters/seters - яркий пример этого.)
Пространства имен не так много проблем в Python, потому что вы можете предоставить модулям псевдоним при импорте. Например:
import com.company.actualpackage as shortername
Таким образом, вы можете не только создавать или манипулировать пространством имен в своих программах, но и создавать собственные псевдонимы для сохранения нажатия клавиш.
У конвенций Java также есть свои недостатки. Не каждый пакет с открытым исходным кодом имеет стабильный веб-сайт. Что должен делать заказчик, если его сайт изменится? Кроме того, использование этих имен пакетов пакетов становится длинным и трудно запоминающимся. Наконец, имя пакета должно представлять цель пакета, а не его владельца
Для пакетов Python не существует соглашения об именах, подобных Java. Конечно, вы можете принять его для любого пакета, который вы разрабатываете самостоятельно, но вам может потребоваться инвазивно редактировать любой пакет, который вы можете принять от третьих лиц, и соглашение об именовании "культурно чуждых", вероятно, сотнет изменения ваших собственных пакетов, которые будут широко приняты вне вашей организации.
Технически, не было бы ничего плохого в Java-конгрессе в Python (это просто сделало бы некоторые инструкции from еще длиннее, неважно), но на практике культурные аспекты делают его практически неосуществимым.
Причина, по которой обычно нет иерархии пакетов, заключается в том, что пакеты Python не так легко расширяются. Пакеты - это фактические каталоги, и хотя вы можете сделать пакеты в нескольких каталогах для подмодулей (добавив каталоги в список __path__ пакета), это не удобно и легко сделано неправильно. Что касается того, почему пакеты Python не так легко расширяются таким образом, ну, это выбор дизайна. Гвидо не любил глубокие иерархии (и до сих пор этого не делает) и не считает нужным.
Соглашение состоит в том, чтобы выбрать имя пакета верхнего уровня, которое является очевидным, но уникальным для вашего проекта - например, имя самого проекта. Вы можете структурировать все внутри него, но вы хотите (потому что вы контролируете его). Разделение пакета на отдельные биты с отдельными владельцами - это немного больше работы, но с несколькими рекомендациями, которые это возможно. Это редко нужно.
Ничего не мешает вам использовать это соглашение, если вы этого хотите, но это вовсе не стандарт в мире Python, и вы, вероятно, получите забавные взгляды. Не очень весело следить за администрированием пакетов, если они глубоко вложены в com.
Это может показаться неаккуратным для кого-то, кто приходит с Java, но на самом деле это, похоже, не вызвало больших трудностей даже с пакетами, так называемыми web.py.
Место, где вы часто сталкиваетесь с конфликтами пространства имен на практике, является относительным импортом: где код в package.module1 пытается import module2, и там есть как package.module2, так и module2 в стандартной библиотеке (что обычно поскольку stdlib большой и растет). К счастью, неоднозначный относительный импорт уходит.
Обновление для всех, кто ищет это:
Начиная с 2012 года, PEP 423 разрешает это. PEP 8 затрагивает тему кратко, но только для того, чтобы сказать: все строчные или подчеркивания.
Суть его: выбрать запоминающиеся, значимые имена, которые еще не используются в PyPI.
Я использую python в течение многих лет и 99.9% от коллизий, которые я видел у новых разработчиков, пытающихся назвать файл "xml.py". Я вижу некоторые преимущества для схемы Java, но большинство разработчиков достаточно умны, чтобы выбирать разумные имена пакетов, поэтому на самом деле это не проблема.