Почему языкам нравится использование Java иерархические имена пакета, в то время как Python не делает?

Python не делает этого, потому что Вы заканчиваете с проблемой - кто владеет "com" пакетом, из которого почти все остальное является подпакетом? Метод Python установления иерархии пакета (через иерархию файловой системы) не играет хорошо с этой конвенцией вообще. Java может выйти сухим из воды, потому что иерархия пакета определяется структурой строковых литералов, питаемых к оператору 'пакета', таким образом, не должно быть явного "com" пакета нигде.

Существует также вопрос того, что сделать, если Вы хотите публично выпустить пакет, но не владеете доменным именем, это подходит для bodging на имя пакета, или если Вы заканчиваете тем, что изменились (или проиграли) Ваше доменное имя по некоторым причинам. (Позже для обновлений нужно другое имя пакета? Как Вы знаете, что com.nifty_consultants.nifty_utility является более новой версией com.joe_blow_software.nifty_utility? Или, с другой стороны, как Вы знаете, что это не более новая версия? Если Вы пропускаете свое доменное обновление, и имя схвачено доменным туристом, и кто-то еще покупает имя от них, и они хотят публично выпустить пакеты программного обеспечения, они должны затем использовать то же имя, которое Вы уже использовали?)

Доменные имена и имена пакета программного обеспечения, это кажется мне, решают две совершенно различных проблемы и имеют совершенно различные усложняющие факторы. Мне лично не нравится конвенция Java, потому что (по моему скромному мнению), она нарушает разделение проблем. Предотвращение конфликтов пространства имен хорошо и все, но я ненавижу мысль о пространстве имен моего программного обеспечения, определяемом (и зависящий от) маркетинговое взаимодействие отдела с некоторой сторонней бюрократией.

Прояснять мою мысль далее, в ответ на комментарий JeeBee: В Python пакет является каталогом, содержащим __init__.py файл (и по-видимому один или несколько файлов модуля). Иерархия пакета требует, чтобы каждый высокоуровневый пакет был полным, законным пакетом. Если два пакета (особенно от различных поставщиков, но даже not-directly-related пакеты от того же поставщика) совместно используют имя пакета верхнего уровня, является ли то имя 'com' или 'сетью' или 'utils' или что бы то ни было, каждый должен обеспечить __init__.py для того пакета верхнего уровня. Мы должны также предположить, что эти пакеты, вероятно, будут установлены в том же месте в дереве каталогов, т.е. пакетах сайта / [pkg] / [subpkg]. Файловая система таким образом осуществляет это существует только один [pkg]/__init__.py - таким образом, какой побеждает? Нет (и не может быть), общий случай корректный ответ на тот вопрос. И при этом мы не можем обоснованно объединить эти два файла вместе. Так как мы не можем знать то, что другой пакет, возможно, должен был бы сделать в этом __init__.py, подпакеты, совместно использующие пакет верхнего уровня, как может предполагаться, не работают, когда оба установлены, если они конкретно не записаны, чтобы быть совместимыми друг с другом (по крайней мере, в этом файле). Это было бы кошмаром распределения и будет в значительной степени делать недействительным весь смысл вложенных пакетов. Это не характерно для иерархий пакета обратного доменного имени, хотя они обеспечивают самый очевидный плохой пример, и (IMO) философски сомнительны - это - действительно практическая проблема общих пакетов верхнего уровня, а не философские вопросы, которые являются моим основным беспокойством здесь.

(С другой стороны, единственный большой пакет с помощью подпакетов для лучше организации себя является прекрасной идеей, так как те подпакеты специально предназначены, чтобы работать и сосуществовать. Это не настолько распространено в Python, тем не менее, потому что единственный концептуальный пакет не имеет тенденцию требовать, чтобы достаточно большому количеству файлов был нужен дополнительный слой организации.)

"Каковы причины, которые Вы предпочли бы один по другому?"

Стиль Python более прост. Стиль Java позволяет продукты того-же-имени от различных организаций.

"Те причины применяются через языки?"

Да. Вы можете легко иметь верхний уровень пакеты Python, названные "com", "org", "миллиметром", "сетью", "edu" и "губернатором", и поместить Ваши пакеты как подпакеты в них.

Править. У Вас есть некоторая сложность, когда Вы делаете это, потому что все должны сотрудничать и не загрязнить эти пакеты верхнего уровня их собственным хламом.

Python не начинал делать это, потому что конфликт пространства имен - на практике - оказывается довольно редким.

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

Люди Java не предвидели Сообщество разработчиков ПО с открытым исходным кодом, выбирающее странные из ряда вон выходящие уникальные имена для предотвращения коллизий имени. Все, кто пишет xml синтаксический анализатор, интересно, не называют его "синтаксическим анализатором". Они, кажется, называют это "саксом" или "Xalan" или чем-то абсолютно странным.

Это - отличный способ предотвращения коллизий имени и в полной мере пользуется существующей системой доменных имен, таким образом, это не требует никакой дополнительной бюрократии или регистрации. Это является простым и блестящим.

Путем инвертирования доменного имени это также дает ему иерархическую структуру, которая удобна. Таким образом, у Вас могут быть подпакеты на конце.

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

Почему библиотеки JavaScript не делают этого, например? Их глобальное пространство имен является большой проблемой, все же библиотеки Javascript используют простые глобальные идентификаторы как '$', которые сталкиваются с другими библиотеками Javascript.

Где-нибудь на Joel на программном обеспечении, у Joel есть сравнение между двумя методами роста компании: метод Ben & Jerry, который начинает с малого и растет органически, и метод Amazon повышения большого количества денег и провешивания на очень широкие требования от запуска.

Когда Sun представил Java, это было с помпой и шумиха. Java, как предполагалось, вступал во владение. Большая часть будущей соответствующей разработки программного обеспечения была бы на предоставляемых через Интернет апплетах Java. Были бы духовые оркестры и даже пони. В этом контексте было разумно установить, впереди, соглашение о присвоении имен, которое было основано на Интернете, благоприятно для корпорации, и в планетарном масштабе.

Хорошо, это не складывалось вполне, как Sun надеялся, но они запланировали, как будто они успешно выполнятся. Лично, я презираю проекты, которые может нарушить успех.

Python был проектом Guido van Rossum первоначально, и это было некоторое время, прежде чем сообщество было уверено, что он выжил бы, если бы van Rossum был поражен шиной. Были, насколько я знаю, никакая начальная буква не планирует принять мир, и он не был предназначен как веб-язык апплета.

Поэтому во время стадий формирования языка, не было никакой причины хотеть обширную иерархию для схемы именования. В том более неофициальном сообществе каждый выбрал более или менее причудливое название проекта и проверил, чтобы видеть, использовал ли кто-то еще уже его. (Именование языка программирования после британского шоу комедии можно было бы считать причудливым только для запуска.) Не было никакой воспринятой потребности угодить большой, но лишенной воображения и неуклюжей схеме именования.

Python действительно имеет его, это - просто намного более плоская иерархия. Посмотрите на os.path, например. И нет ничего разработчиков библиотеки остановки, делающих намного более глубокие, например, Django.

Существенно, я думаю, что Python разработан на идее, что Вы хотите получить материал, обошедшийся без, имея необходимость указать или ввести слишком много заранее. Это значительно помогает с использованием командной строки и сценариями. Существует несколько частей 'Дзэн Python', которые обращаются к объяснению для этого:

• Простой лучше, чем комплекс.
• Плоский лучше, чем вложенный.
• Красивый лучше, чем ужасный. (Система Java выглядит ужасной мне.)

С другой стороны, существует:

• Пространства имен являются одной гудящей прекрасной идеей - давайте сделаем больше из тех!

Идея состоит в том, чтобы сохранить пространства имен бесконфликтными. Вместо нечитабельных UUID и т.п., вряд ли будет стоять на пути обратное доменное имя. Очень простой, но прагматичный. Кроме того, когда использование третьей стороны освобождает его, мог бы дать Вам ключ к разгадке как, туда, где они произошли из (для обновлений, поддержка и т.д.)

Java может сделать это как это, так как это - рекомендуемая общепринятая практика Java, и в значительной степени универсально принятый сообществом Java. DOS Python не имеет эту конвенцию.