Стало интересно, что это за файлы. Я так понимаю - это некий байт-код для питоновского интерпретатора, что-то вроде .msi в .NET. А не знает ли кто, где можно почитать про анотомию этих файлов, формат, каким образом получается этот самый байт-код. Или это секрет разработчиков интерпретатора?

В общем если у кого есть что-нибудь интересное по данной теме - поделитесь плиз или дайте ссылку. Заранее всем спасибо :)

начнем с того, что msi - это инсталлятор, в первую голову. Из аналогов в Питоне - egg. Хоть и структура/способы работы с ним далеко не так кошмарны, как с msi.
pyc/pyo - только байткод. pyo - с оптимизацией (реально ничего не дает, только докстринги режутся, как я помню. Интрерпретатору приходится так и так одинаково трудиться)
Когда импортим модуль - получаем объект. Если его пропустить через стандартный marshal и прибавить в начале магический код (константа, определяющая тип файла) - получим pyc. Может я что-то и забыл, но это, ИМХО, несущественно. По крайней мере в работе никогда не понадобилось.
Где-то видел (возможно, даже сдесь) более подробное описание со ссылками на исходники Питона.

http://crchemist.wmn.cc/?p=9
http://crchemist.wmn.cc/?p=11
http://crchemist.wmn.cc/?p=12

Андрей Светлов
pyc/pyo - только байткод. pyo - с оптимизацией (реально ничего не дает, только докстринги режутся, как я помню. Интрерпретатору приходится так и так одинаково трудиться)

Неправда. При выполнении pyo внутренняя переменная интерпретатора __debug__ устанавливается в 0.
Эта переменная используется в операторе assert. Так что можно считать что в pyo отсутствуют assert.

pyo получаются при запуске python -O или python -OO. Но! Докстринги режутся только при выполнении python -OO. Поэтому pyo может содержать, а может и не содержать докстринги.

Да, точно. Но на скорость исполнения это практически не влияет. Другое дело, если o2 в С++ компиляторе включишь!

bialix

Андрей Светлов
pyc/pyo - только байткод. pyo - с оптимизацией (реально ничего не дает, только докстринги режутся, как я помню. Интрерпретатору приходится так и так одинаково трудиться)

Неправда. При выполнении pyo внутренняя переменная интерпретатора __debug__ устанавливается в 0.
Эта переменная используется в операторе assert. Так что можно считать что в pyo отсутствуют assert.

pyo получаются при запуске python -O или python -OO. Но! Докстринги режутся только при выполнении python -OO. Поэтому pyo может содержать, а может и не содержать докстринги.

Запускаю python -OO file | python -O file но pyc/pyo не появляются. Или их в другом месте появляются?

AndreyKS

bialix

Андрей Светлов
pyc/pyo - только байткод. pyo - с оптимизацией (реально ничего не дает, только докстринги режутся, как я помню. Интрерпретатору приходится так и так одинаково трудиться)

Неправда. При выполнении pyo внутренняя переменная интерпретатора __debug__ устанавливается в 0.
Эта переменная используется в операторе assert. Так что можно считать что в pyo отсутствуют assert.

pyo получаются при запуске python -O или python -OO. Но! Докстринги режутся только при выполнении python -OO. Поэтому pyo может содержать, а может и не содержать докстринги.

Запускаю python -OO file | python -O file но pyc/pyo не появляются. Или их в другом месте появляются?

pyc/pyo файлы создаются только для импортируемых модулей/библиотек и никогда для выполняемого скрипта.

Murr_vk
Я так понимаю - это некий байт-код для питоновского интерпретатора, что-то вроде .msi в .NET.

Думаю, ты имел ввиду MSIL (Microsoft Intermediate Language), а не .msi?

bialix, а можно “откомпилировать” сам скрипт? Например, чтобы не показывать исходник?

Mr.Floppy
bialix, а можно “откомпилировать” сам скрипт? Например, чтобы не показывать исходник?

можно, но питоновский байт-код декомпилируется на раз-два по многочисленным утверждениям опытных товарищей. так что как написано в книге Core Python Programming для особо секретных частей писать сишные (или Pyrex-ные – это от меня совет) расширения. А сам главный скрипт пистатьчто-то вроде:


from mylib import main
main()


тогда бояться показывать исходник не придется :-)