Способ собрать файлы Python в отдельной папке?

Question

Возможно ли, чтобы Python сохранил файлы .pyc в отдельной папке, которая находится в sys.path?

/code
    foo.py
    foo.pyc
    bar.py
    bar.pyc

Кому:

/code
   foo.py
   bar.py
/code_compiled
   foo.pyc
   bar.pyc

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

Answer 1

В мрачные и древние дни 2003 года появился PEP 304, чтобы решить эту проблему. Его патч был найден бессмысленным. Зависимости среды от платформы и перекосы версий порвали ее в клочья и оставили разбросанные по пустошам биты.

После многих лет страданий в последние дни 2009 года поднялся новый претендент. Барри Варшава вызвал PEP 3147 и отправил его в бой, используя простое оружие с умением. PEP уничтожил загроможденные файлы PYC, заставил замолчать интерпретатора Unladen Swallow и CPython, каждый из которых пытался доказать, что его файл PYC должен быть триумфальным, и позволил Python успокоиться с его мертвыми призраками, иногда работающими в глубокой ночи. ОПТОСОЗ 3147 был признан диктатором достойным и был посвящен в официальные роли в дни 3.2.

Начиная с 3.2, Python хранит файлы PYC модуля в __pycache__ в каталоге модуля. Каждый файл PYC содержит имя и версию интерпретатора, например, __pycache__/foo.cpython-33.pyc. Вы также можете иметь __pycache__/foo.cpython-32.pyc, скомпилированный более ранней версией Python. Происходит правильное волшебство: правильное используется и перекомпилируется, если не синхронизировано с исходным кодом. Во время выполнения посмотрите в модуле mymodule.__cached__ имя файла pyc и проанализируйте его с помощью imp.get_tag(). См. раздел «Что нового» * ​​1015 * для получения дополнительной информации.

TL; DR - Просто работает в Python 3.2 и выше. Плохие хаки заменяют версии до этого.

Answer 2

Существует PEP 304: Управление генерацией файлов байт-кода . Его статус Withdrawn и соответствующий патч отклонен. Поэтому не может быть прямого способа сделать это.

Если вам не нужен исходный код, вы можете просто удалить *.py файлы. *.pyc файлы могут быть использованы как есть или упакованы в яйцо.

Answer 3

Если вы готовы полностью пожертвовать генерацией байт-кода, есть флаг командной строки:

python -B file_that_imports_others.py

Может быть добавлено в настройки сборки / запуска IDE

Answer 4

Я не согласен. Причины неверны или, по крайней мере, не очень хорошо сформулированы; но направление действительно. Есть веские причины для возможности отделить исходный код от скомпилированных объектов. Вот несколько из них (все из которых я столкнулся в тот или иной момент):

• встроенное устройство считывает данные из ПЗУ, но может использовать файловую систему в оперативной памяти в ОЗУ.
• multi-os dev среда означает совместное использование (с samba / nfs / чем угодно) моего рабочего каталога и сборку на нескольких платформах.
• коммерческая компания желает распространять только pyc для защиты IP
• легко запустить набор тестов для нескольких версий Python, используя один и тот же рабочий каталог
• проще очищать переходные файлы (rm -rf $ OBJECT_DIR вместо поиска. -Name '* .pyc' -exec rm -f {} \;)

Есть обходные пути для всех этих проблем, НО они в основном обходные пути, а НЕ решения. Правильным решением в большинстве этих случаев было бы для программного обеспечения принять альтернативное местоположение для хранения и поиска этих переходных файлов.

Answer 5

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

Если вам действительно не нравится расположение этих файлов pyc, альтернативой является запуск из папки только для чтения. Поскольку python не сможет писать, pyc-файлы никогда не создаются. Удар, который вы принимаете, заключается в том, что каждый файл Python должен быть перекомпилирован сразу после загрузки, независимо от того, изменили вы его или нет. Это означает, что ваше время запуска будет намного хуже.

Answer 6

И только спустя почти десять лет Python 3.8 наконец-то предоставляет поддержку для хранения байт-кода в отдельном параллельном дереве файловой системы, устанавливая переменную окружения PYTHONPYCACHEPREFIX или используя аргумент -X pycache_prefix=PATH (официальный документ здесь ).

Answer 7

Поскольку Python 3.2 был реализован PEP 3147 : это означает, что все файлы .pyc создаются в каталоге __ pycache __ (будет __ pycache __ каталог для каждого каталога, где у вас есть файлы Python, и он будет содержать файлы .pyc для каждой версии Python, используемой в источниках)

Answer 8

Существует постоянный pep, который разрешит создание байт-кода в магическом каталоге .

В основном все файлы Python будут скомпилированы в каталог __pythoncache__.

Answer 9

Для Python 3.8 или выше:

Параметр PYTHONPYCACHEPREFIX (также доступен как -X pycache_prefix) настраивает неявный кэш байт-кода для использования отдельного дерева файловой системы, а не подкаталогов __pycache__ по умолчанию в каждом исходном каталоге. 1008 *

Расположение кэша указывается в sys.pycache_prefix (None указывает местоположение по умолчанию в подкаталогах __pycache__).

Answer 10

«Я чувствую, что это было бы более организованно». Почему? Как? Что вы пытаетесь достичь?

Смысл сохранения выходных данных компилятора состоит в том, чтобы сэкономить крошечное время загрузки при импорте модуля. Зачем делать это более сложным? Если вам не нравятся файлы .pyc, то периодически запускайте скрипт «delete all .pyc».

Они не важны; они полезны Зачем отключать эту помощь?

Это не C, C ++ или Java, где результирующие объекты важны. Это просто кеш, который использует Python. Мы помечаем их как «игнорируемые» в Subversion, чтобы они случайно не регистрировались.