Возможно ли, что Python сохранит файлы .pyc в отдельном местоположении папки, которое находится в sys.path?
/code
foo.py
foo.pyc
bar.py
bar.pyc
To:
/code
foo.py
bar.py
/code_compiled
foo.pyc
bar.pyc
Мне хотелось бы этого, потому что я чувствую, что он будет более организованным. Спасибо за любую помощь, которую вы можете мне дать.
Существует PEP 304: Управление генерацией файлов байткода. Его статус Withdrawn и соответствующий patch отклонен. Поэтому не может быть прямого способа сделать это.
Если вам не нужен исходный код, вы можете просто удалить *.py файлы. *.pyc файлы могут быть использованы как есть или упакованы в яйцо.
В темные и древние дни 2003 года PEP 304 вышел, чтобы бросить вызов этой проблеме. Его патч был найден желательным. Зависимости переменных переменных среды и версии перекоса разорвали его на клочки и оставили его биты, разбросанные по пустошам.
После долгих лет страданий новый соперник поднялся в последние дни 2009 года. Барри Варшава вызвал PEP 3147 и отправил его на битву, используя умное оружие. PEP разгромил беспорядочные файлы PYC, заглушил испорченный интерпретатор 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 должен быть перекомпилирован сразу после его загрузки, независимо от того, изменили ли вы его или нет. Это означает, что время запуска будет намного хуже.
Я не согласен. Причины неправильны или, по крайней мере, недостаточно хорошо сформулированы; но направление действительно. Есть веские причины для того, чтобы отделить исходный код от скомпилированных объектов. Вот некоторые из них (все из них, с которыми я столкнулся в какой-то момент):
Существуют обходные пути для всех этих проблем, но они в основном обходные решения НЕ. Правильное решение в большинстве этих случаев было бы для программного обеспечения принимать альтернативное место для хранения и поиска этих переходных файлов.
Если вы готовы пожертвовать поколением байт-кода для него, там есть флаг командной строки:
python -B file_that_imports_others.py
Может быть помещен в настройки сборки/запуска IDE
Существует постоянный pep, который будет включить построение байт-кода в волшебный каталог.
В основном все файлы python будут скомпилированы в каталог __pythoncache__.
Так как Python 3.2 был реализован PEP 3147: это означает, что все .pyc файлы создаются внутри __pycache __ (будет каталог __pycache __ для каждого каталога, где у вас есть файлы Python, и он будет хранить файлы .pyc для каждой версии Python, используемой в источниках)
И только спустя почти десять лет Python 3.8 наконец-то предоставляет поддержку для сохранения байт-кода в отдельном параллельном дереве файловой системы, устанавливая переменную окружения PYTHONPYCACHEPREFIX или используя -X pycache_prefix=PATH (официальный документ здесь).
Параметр PYTHONPYCACHEPREFIX (также доступный как -X pycache_prefix) настраивает неявный кэш байт-кода для использования отдельного дерева файловой системы, а не подкаталогов __pycache__ по умолчанию в каждом исходном каталоге.
Расположение кэша указывается в sys.pycache_prefix (None указывает местоположение по умолчанию в подкаталогах __pycache__).
"Я чувствую, что это было бы более организованным". Почему? Как? Что вы пытаетесь выполнить?
Точкой сохранения вывода компилятора является сохранение минимального времени загрузки, когда модуль импортируется. Зачем сделать это более сложным? Если вам не нравятся .pyc, тогда запустите "удалить все".pyc "script периодически.
Они не являются существенными; они полезны. Зачем отключать эту помощь?
Это не C, С++ или Java, где результирующие объекты необходимы. Это всего лишь кеш, который использует Python. Мы отмечаем их как "проигнорированные" в Subversion, поэтому они случайно не завершают проверку.