#python #import
#python #импорт
Вопрос:
Что я хочу понять, так это то, что является хорошей / плохой практикой и почему, когда дело доходит до импорта. Что я хочу понять, так это согласованное мнение сообщества по этому вопросу, если таковое имеется в каком-либо документе PEP или подобном.
Обычно я вижу, что у людей есть среда python, они используют conda / pip для установки пакетов, и все, что нужно сделать в коде, это использовать «import X» (и варианты). В моем нынешнем понимании это правильный способ делать вещи.
Однако всякий раз, когда python взаимодействует с C в моей фирме, это всегда заканчивается необходимостью использования sys.path и абсолютного импорта (но у нас есть несколько стандартизированных путей для использования в качестве «базовых» и обычно мы определяем относительные пути на их основе).
Есть 2 основных случая:
- Python-оболочка для библиотеки C (pybind/ ctype /etc) — в этом случае пользовательский код python должен использовать sys.path, чтобы указать, где находится библиотека C для импорта.
- Проект, который устанавливает связь между python и C (скажем, сервер C , клиенты python, TCP-соединения и сериализация плоского буфера между ними) — здесь код python живет вместе с кодом C , и если некоторые файлы python в конечном итоге используют sys.path для импорта модулей python из того жепроект, но который находится в другом каталоге — по сути, мы развертываем python вместе с C с помощью нашей процедуры развертывания C .
Я не совсем уверен, можем ли мы сделать что-то лучше для случая № 1, но случай № 2 кажется совершенно ненужным и в основном вызван просто выбором не развертывать код python через менеджер пакетов python. Выбор в конечном итоге заставляет нас использовать sys.path как в библиотеке, так и в пользовательском коде.
Мне это кажется очень плохим, поскольку в основном такой способ ведения дел не позволяет нам полностью управлять нашими средами python (поскольку у нас есть некоторые библиотеки, которые мы импортируем, даже если они технически не установлены в среде), и, вероятно, поэтому я отрицательно отношусь к использованию sys.path дляимпортирует. Но мне нужно выяснить, прав ли я, и если да, мне нужны некоторые официальные (или почти) документы в поддержку моего дела, если я хочу предложить исправления для наших процедур.
Комментарии:
1. Вы в курсе
PYTHONPATH?2. @MisterMiyagi Да, и моя фирма тоже в курсе. Однако он не используется. Тем не менее, я лично также не уверен, когда это хорошо использовать, а когда нет, поскольку существование функции в python ничего не говорит о том, когда ее стоит использовать, и иногда, если это вообще хорошая идея.
3. Что я имею в виду выше, так это то, что это кажется способом избежать sys.path, но у вас по-прежнему такой же недостаток контроля над вашей средой python, поскольку вы добавляете вещи, которые невидимы с точки зрения менеджера пакетов (что также означает, что я не могу указать их в качестве требований, если я создаю пакет для pip/conda, именно так я развертываю свой код на python).
4. Я не в курсе каких-либо официальных рекомендаций, так что это просто личный комментарий. Проблема расширения
sys.path(при условии, что это сделано правильно с самого начала) заключается в том, что скрипты жестко кодируют свои зависимости.PYTHONPATHрешает это путем разделения сценариев и их зависимостей; вы все равно можете отказаться от него позже в пользу правильно установленных пакетов без изменения сценариев.
Ответ №1:
Для вашего сценария 2, насколько я понимаю, у вас есть некоторый C и сопутствующий python в одном месте, и отдельный проект python хочет импортировать этот python.
Не могли бы вы структурировать импортированный python в виде пакета и установить его в свою среду с pip install path/to/package помощью? Если это пакет, который вы будете продолжать редактировать, вы можете добавить -e флаг pip install , чтобы при изменении пакета ваш импорт получал последний код.
Комментарии:
1. Я не контролирую этот проект. Питон просто лежит там, без единого init.py , вообще не организован как пакет python. Более того, в настоящее время мы вынуждены использовать conda (и anaconda), которые, я думаю, не имеют эквивалента
pip install -e. Кроме того, честно говоря, я воспринимаю that -e как удобную функцию для разработки, но не предназначенную для производственного использования. Может быть, я слишком строг в своих взглядах?2. Вы все равно можете использовать pip, если находитесь в среде conda. Активируйте окружение, тогда первым пунктом на вашем пути будет пункт окружения.
3. Хотя я согласен, что -e — не очень хорошая идея для производства. Если это код, контролируемый кем-то другим, я не думаю, что вам нужно его редактировать, поэтому флаг -e не понадобится. Однако вы все равно можете установить его с помощью pip! Это должны быть те сопровождающие проекта, которые добавляют структуру пакета python, поэтому, если вы предпочитаете избегать путей, я рекомендую запросить это у них, или, если они неохотно предлагают сделать запрос на извлечение с изменением.