Способ скомпилировать файлы python в отдельную папку?

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

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

в:

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

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

8 ответов


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

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


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

после многих лет страданий, новый претендент вырос в последние дни 2009 года. Барри Варшава вызвал PEP 3147 и отправил его в бой, умело орудуя простым оружием. ОПТОСОЗ раздавил захламление Файлы PYC, заставили замолчать waring Unladen Swallow и интерпретатор CPython, каждый из которых пытался доказать, что его файл PYC должен быть триумфальным, и позволил Python спокойно отдыхать с его мертвыми призраками, иногда бегущими в глухую ночь. PEP 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(). См.что нового раздела для получения дополнительной информации.

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


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

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


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

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

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


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

python -B file_that_imports_others.py

можно поместить в настройки сборки/запуска IDE


продолжается оптосоз, который будет включить создание байт-кода в magic directory.

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


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


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

смысл сохранения выходных данных компилятора заключается в сохранении крошечного времени загрузки при импорте модуля. Зачем делать больше этот комплекс? Если тебе не нравится .pyc, затем запустите "удалить все .сценарий pyc " периодически.

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

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