Соглашения о присвоении имен пакета Python
Есть ли соглашение о присвоении имен пакета для Python как Java com.company.actualpackage? Большую часть времени я вижу простой, потенциально сталкивающиеся имена пакета как "сеть".
Если нет такой конвенции, есть ли причина его? Что Вы думаете об использовании соглашения о присвоении имен Java в мире Python?
6 ответов
У Python есть две «мантры», охватывающие эту тему:
Явное лучше, чем неявное.
и
Пространства имен - одна отличная идея - давайте сделаем еще больше!
Существует соглашение об именах и импорте модулей, которое можно найти в The Python Style Guide (PEP 8).
Самая большая причина того, что не существует такого соглашения о постоянном префиксе имен ваших модулей в стиле Java, заключается в том, что со временем вы в конечном итоге получаете много повторений в вашем коде, которых на самом деле не должно быть.
Одна из проблем Java заключается в том, что она заставляет вас постоянно повторяться. В код Java входит множество шаблонов, которые просто не нужны в Python. (Геттеры / сеттеры являются ярким примером этого.)
Пространства имен не являются большой проблемой в Python, потому что вы можете дать модулям псевдоним при импорте. Например:
import com.company.actualpackage as shortername
Таким образом, вы не только можете создавать или управлять пространством имен в своих программах, но также можете создавать свои собственные псевдонимы, сохраняющие нажатие клавиш.
Я использую Python в течение многих лет, и 99,9% столкновений, которые я видел, исходили от новых разработчиков, которые пытались назвать файл «xml.py». Я вижу некоторые преимущества схемы Java, но большинство разработчиков достаточно умны, чтобы выбирать разумные имена пакетов, так что это действительно не такая уж большая проблема.
Ничто не мешает вам использовать это соглашение, если вы хотите, но это совсем не стандартно в мире Python, и вы, вероятно, получите забавный вид. Не очень интересно заботиться об администраторе пакетов, когда они глубоко вложены в com .
Это может показаться неаккуратным для кого-то, пришедшего с Java, но на самом деле это не вызывает каких-либо серьезных затруднений, даже с пакетами с такими неудачными названиями, как web.py.
На практике часто возникают конфликты пространств имен при относительном импорте: код в package.module1 пытается импортировать module2 , и оба package.module2 и module2 в стандартной библиотеке (которая обычно есть, поскольку stdlib большой и постоянно растет). К счастью, неоднозначный относительный импорт уходит .
Соглашения Java также имеют свои недостатки. Не за каждым пакетом с открытым исходным кодом стоит стабильный веб-сайт. Что делать сопровождающему, если его веб-сайт изменится? Кроме того, при использовании этой схемы имена пакетов становятся длинными и запоминающимися. Наконец, имя пакета должно отражать цель пакета, а не его владельца
Причина, по которой обычно нет иерархии пакетов, заключается в том, что пакеты Python не так легко расширить таким образом. Пакеты - это фактические каталоги, и хотя вы можете заставить пакеты искать подмодули в нескольких каталогах (добавляя каталоги в список __ path __ пакета), это неудобно и легко ошибиться. Что касается , почему пакеты Python нелегко расширить таким образом, ну, это выбор дизайна. Гвидо не любил (и до сих пор не любит) глубоких иерархий и не считает их необходимыми.
Согласно соглашению, имя пакета верхнего уровня должно быть очевидным, но уникальным для вашего проекта - например, имя самого проекта. Вы можете структурировать все внутри него, как хотите (потому что вы контролируете это). Разделение пакета на отдельные части с разными владельцами - это немного больше работы, но с некоторыми рекомендациями это возможно. Это редко нужно.
Для пакетов Python не существует соглашения об именах в стиле Java. Вы, конечно, можете принять его для любого пакета, который вы разрабатываете самостоятельно, но вам, возможно, придется инвазивно редактировать любой пакет, который вы можете принять от третьих сторон, и «культурно чуждое» соглашение об именах, вероятно, приведет к тому, что изменения ваших собственных пакетов будут широко приняты. вне вашей организации.
Технически, в соглашении Java в Python не было бы ничего плохого (это просто сделало бы некоторые из утверждения немного длиннее, ничего страшного), но на практике культурные аспекты делают это в значительной степени невыполнимым.