Python .py, .pyo, *.pyc: что можно устранить для встроенной системы?

Чтобы втиснуться в ограниченное количество хранилища файловой системы, доступного во встроенной системе, с которой я сейчас играю, я хотел бы исключить любые файлы, которые можно было бы разумно удалить без существенного влияния на функциональность или производительность. Файлы *.py, *.pyo и *.pyc в учетной записи библиотеки Python для значительного объема пространства, мне интересно, какой из этих параметров будет наиболее разумным для установки Python 2.6 в небольшой встроенной системе:

Сохранить *.py, исключить *.pyc и *.pyo(Поддерживать способность отладки, производительность страдает?)
Сохранить *.py и *.pyc, исключить *.pyo(действительно ли оптимизация действительно что-то покупает?)
Сохранить *.pyc, исключить *.pyo и *.py(будет ли это работать?)
Сохранить *.py, *.pyc и *.pyo(все нужны?)

Ответ 1

http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html

Когда интерпретатор Python вызывается с флагом -O, оптимизированный код генерируется и сохраняется в файлах .pyo. Оптимизатор в настоящее время мало помогает; он только удаляет утверждения assert.

Передача двух-O-флагов интерпретатору Python (-OO) заставит компилятор байт-кода выполнить оптимизации, которые в некоторых редких случаях могут привести к сбоям в работе программ. В настоящее время из байт-кода удаляются только строки doc, что приводит к более компактным файлам .pyo.

Мое предложение для вас?

Используйте -OO для компиляции только файлов .pyo, если вам не нужны команды assert и строки __doc__.

В противном случае используйте .pyc.

Edit

Я заметил, что вы только упоминали библиотеку Python. Большая часть библиотеки python может быть удалена, если вам нужна только часть функциональности.

Я также предлагаю вам взглянуть на tinypy, который является большим подмножеством Python примерно в 64 КБ.

Ответ 2

Номер 3 должен и будет работать. Вам не нужны файлы .pyo или .py, чтобы использовать скомпилированный код python.

Ответ 3

Я бы рекомендовал хранить только .py файлы. Разница во времени запуска не так уж велика, а источник вокруг - это плюс, поскольку он будет работать под разными версиями python без каких-либо проблем.

Как и в случае с python 2.6, установка sys.dont_write_bytecode в True будет полностью подавлять компиляцию файлов .pyc и .pyo, поэтому вы можете использовать эту опцию, если у вас есть 2.6.

Ответ 4

В конечном итоге это сводится к тому, что вам действительно нужен только один из трех вариантов, но лучше всего пойти с .pys и либо .pyos, либо .pycs.

Здесь, как я вижу каждый из ваших вариантов:

Если вы поместите файл .pys в zip файл, вы не увидите pyc или pyos. Следует также отметить, что разница в производительности только во время запуска, и даже тогда это не слишком велико в моем опыте (ваше возражение может измениться). Также обратите внимание, что есть способ предотвратить вывод интерпретатора .pycs как Algorias.
Я думаю, что это идеальный вариант (или это .pys и .pyos), потому что вы получаете лучшее сочетание производительности, отладки и надежности. Однако вам необязательно нужен исходный файл и скомпилированный файл.
Если вы действительно привязаны к пространству и нуждаетесь в производительности, это сработает. Я бы посоветовал вам сохранить .pys, если это вообще возможно. Скомпилированные двоичные файлы (.pycs или .pyos) не всегда передаются в разные версии python.
Сомнительно, что вам понадобятся все три, если вы не планируете иногда работать в оптимизированном режиме и не оптимизированном режиме.

В терминах пространства это был мой (очень анекдотический) опыт:.py файлы сжимают лучшее по сравнению с .pycs и .pyos, если вы помещаете их в zip файл. Если вы планируете сжать файлы,.pyos не имеют тенденций выигрывать много в терминах чистого пространства, потому что docstrings имеют тенденцию сжиматься достаточно хорошо и утверждает, что они не занимают столько места.

Ответ 5

Вот как я минимизирую требования к дискам для mainline Python 2.7 при дневном задании:

1) Удалите пакеты из стандартной библиотеки, которые вам не понадобятся. Ниже приведен консервативный список:

bsddb/test ctypes/test distutils/tests email/test idlelib lib-tk
lib2to3 pydoc.py tabnanny.py test unittest

Обратите внимание, что некоторые коды Python могут иметь удивительные зависимости; например setuptools требуется unittest для запуска.

2) Предварительно скомпилируйте весь код Python, используя -OO для удаления утверждений и docstrings.

find -name '*.py' | python -OO -m py_compile -

Обратите внимание, что Python по умолчанию не смотрит файлы .pyo; вы также должны явно спросить об оптимизации во время выполнения, используя параметр или переменную среды. Запустите сценарии одним из следующих способов:

python -OO -m mylib.myscript
PYTHONOPTIMIZE=2 python -m mylib.myscript

3) Удалите .py файлы исходного кода (если вам не нужно запускать их как скрипты) и .pyc unoptimized files.

find '(' -name '*.py' -or -name '*.pyc' ')' -and -not -executable -execdir rm '{}' ';'

4) Сжатие файлов библиотеки Python. Python может загружать модули из zip файла. Пути в zip файле должны соответствовать иерархии пакетов; таким образом, вы должны объединить каталоги site-packages и .egg в каталог основной библиотеки до начала zip-копирования. (Или вы можете добавить несколько файлов zip в путь Python.)

В Linux, путь по умолчанию для Python включает /usr/lib/python27.zip, поэтому просто отпустите zip файл и вы готовы к работе.

Оставьте os.pyo как обычный (без замятия) файл, так как Python ищет это как проверку работоспособности. Если вы переместите его в zip файл, вы получите предупреждение о каждом вызове Python (хотя все будет работать). Или вы можете просто оставить пустой файл os.py и поместить реальный в zip файл.

Заключительные примечания:

Таким образом, Python вмещает 7 МБ дискового пространства. Там гораздо больше можно сделать, чтобы уменьшить размер, но 7 МБ был достаточно мал для моих целей.:)
Байт-код Python несовместим между версиями, но кто заботится, когда это вы делаете компиляцию, а вы, кто управляет версией Python?
.pyo файлы в zip файле должны быть выигрышем во всех случаях, если только диск не работает очень быстро, а процессор/оперативная память очень медленная. В любом случае, Python выполняется из памяти, а не на диске, поэтому это влияет только на производительность при загрузке. Хотя зачистка док-строк может сэкономить немало памяти.
Обратите внимание, что файлы .pyo не содержат операторов assert.
.pyo файлы сохраняют имена функций и номера строк, поэтому отладка не уменьшается: вы по-прежнему получаете хорошие трассировки, вам просто нужно вручную найти номер строки в источнике, что вам все равно придется делать.
Если вы хотите "взломать" файл во время выполнения, просто поместите его в текущий рабочий каталог. Он имеет приоритет над библиотечным zip файлом.