Отключение файлов pyc в производстве

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

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


person Jared Mackey    schedule 07.06.2016    source источник
comment
Можете ли вы более подробно описать проблемы, с которыми вы сталкиваетесь? Может быть лучший вариант - просто отключить их.   -  person skrrgwasme    schedule 07.06.2016
comment
Возможный дубликат Как избежать файлов .pyc?   -  person Bryan P    schedule 19.04.2017


Ответы (2)


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

Мне любопытно, где они вызвали горе в прошлом (вы отключаете измененное время в файловой системе?), Как будто файл .py новее файла .pyc, интерпретатора Python (по крайней мере, в общих реализациях, включая CPython ), будет повторно компилировать исходный код, но это не очень важно для объема этого вопроса.

Если вы импортируете функцию, например:

def my_database_call(budget_id):
    import some_expensive_module_to_import
    some_orm(...).get(budget_id)

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

В случае, который вы упомянули в комментариях, если вы «выкладываете» ОС для вызова скрипта Python и не позволяете записывать байт-код в этом вызове, каждый вызов требует затрат на компиляцию.

person Community    schedule 07.06.2016
comment
Иногда они не перекомпилируются после проверки нового кода с помощью Git. Иногда при отладке может возникнуть серьезная головная боль, потому что файлы pyc являются причиной этих ошибок импорта. Особенно после массовых рефакторингов. - person Jared Mackey; 07.06.2016
comment
О'кей, я вижу, как это происходит. Основное изменение, если вы не разрешаете запись файлов байт-кода, будет увеличивать время запуска. Это может быть очень важно, если ваше приложение выдает исключение в производственной среде и вы полагаетесь на него для перезапуска. - person ; 07.06.2016
comment
Как это повлияет на использование popen для запуска скрипта Python? Мы делаем это очень часто. - person Jared Mackey; 07.06.2016
comment
То же самое - Popen(['python', 'my_script.py']) следует тем же правилам, что и вызов python my_script.py загружает my_script и его импорт в память. Не позволяя сохранять байт-код, он должен анализировать / компилировать каждый исходный файл при каждом вызове - просто более длительное время запуска. - person ; 07.06.2016
comment
Хорошо, так что все могло быть медленнее, знаете ли вы какую-либо документацию о том, насколько медленнее? Я пробовал погуглить, но ничего не вышло. Я понимаю, что это может сильно отличаться в зависимости от приложения и сценария. - person Jared Mackey; 07.06.2016
comment
Ты сделал это. Зависит полностью от приложения, сценария и количества импортов, сложности содержимого файла. И будьте осторожны, медленнее при запуске и начальном импорте. Если вы импортируете за функцией, эта стоимость импорта не будет понесена до тех пор, пока эта функция не будет вызвана, и я верю каждый последующий раз. - person ; 07.06.2016
comment
Не могли бы вы отредактировать свой ответ, включив последний фрагмент? Это действительно актуально и, вероятно, удержит нас от его использования. - person Jared Mackey; 07.06.2016
comment
Готово :) Я собираюсь отправиться на ночь, но я буду рад помочь вам завтра, если у вас все еще есть вопросы, на которые нет ответа. Надеюсь, ответ оказался полезным и удачи! - person ; 07.06.2016

Вы можете попробовать добавить следующий код в свой файл main. Любой модуль, импортированный после, не создаст .pyc:

import sys
sys.dont_write_bytecode=True

Или установите переменную окружения:

PYTHONDONTWRITEBYTECODE

Вы также можете отредактировать или создать свой usercustomize.py, найденный в /site-packages, чтобы он содержал:

import sys
sys.dont_write_bytecode=True

Также можно передать параметр "-B". Что касается удаления или отключения генерации .pyc, последствия кажутся небольшими или неразличимыми. .Pyc создается для повышения скорости. Не скорость программы, а время, необходимое для загрузки. Если вы постоянно importing модуль, то рекомендуется использовать .pyc, потому что он сокращает время загрузки указанных модулей. После исследования, похоже, нет других преимуществ использования / создания .pyc.

person TheLazyScripter    schedule 07.06.2016
comment
Я знаком с тем, как их отключить, но я ищу возможные побочные эффекты при этом. - person Jared Mackey; 07.06.2016
comment
@electrometro Обновлено. - person TheLazyScripter; 07.06.2016