Проверять / отключать проверку и восстановление байт-кода в Python 2 - PullRequest
0 голосов
/ 10 сентября 2018

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

Мой вопрос (ы):

  1. Мой единственный вариант удалить источник .py, оставив только файлы .pyc? (Я не хочу этого делать, потому что хранение исходного кода оказалось очень полезным для отладки в этом сценарии.)
  2. Как я могу проверить это поведение, чтобы увидеть, что на самом деле происходит?

Фон и мотивация

Я создаю пакет модулей Python для распространения по сетевой файловой системе только для чтения, и я включаю предварительно скомпилированный байт-код в виде .pyc вместе с пакетами Python. Я могу гарантировать, что конечные пользователи всегда будут использовать его с одной и той же версией Python, в той же операционной системе Linux, с тем же ядром, в той же среде и т. Д., И поэтому , следовательно, никогда не придется повторно генерировать байт-код . (Это специальная установка для научного эксперимента среднего размера, в котором мы реализуем эти вещи в среде, предоставляемой нашим разработчикам программного обеспечения. Менеджер пакетов в этой среде отказывается устанавливать пакеты, которые не соответствуют друг друга в соответствии с указанными нами способами.)

В этом контексте я хочу убедиться, что Python не пытается перегенерировать байт-код или записывать .pyc, потому что мы хотим избежать медленного запуска при импорте некоторых больших модулей (matplotlib, scipy и некоторых других). Поведение Python по умолчанию, насколько я понимаю, это

  1. всегда проверить, не устарели ли файлы .pyc
  2. всегда восстановить этот байт-код, если он устарел
  3. всегда попробуйте перезаписать файл .pyc новым байтовым кодом и
  4. никогда сообщать пользователю, если перезапись .pyc не удалась.

Шаг 1 не должен быть необходим, но я не слишком беспокоюсь об этом, потому что требуется только проверка нескольких байтов. Я думаю, что это не займет много времени (даже в нашей сетевой файловой системе, которая оптимизирована для обслуживания небольших или частичных двоичных файлов). Я полагаю, что могу ошибаться для пакетов, в которых много файлов .pyc?

Шаг 2 никогда не должен выполняться после сборки пакета. Если это происходит, значит, в управлении пакетами есть ошибка.

Шаг 3 здесь всегда будет неудачным, потому что это файловая система только для чтения. Если это произойдет, нам нужно знать об этом.

Шаг 4 расстраивает, потому что я не могу сказать, что происходит. И я видел модули (например, matplotlib), которые загружаются быстрее при последующем импорте в этом сценарии, чего я не понимаю.

...