я смотрю торрент никому не понравился?)

поставлю качать вечером

Например, библиотеки для языка Python могут распространяться либо в виде файлов с исходным кодом (расширение «py»), либо в виде файлов с байт-кодом[4] (расширение «pyc», буква «c» от англ. compiled

я смотрю торрент никому не понравился?)

а что там? для вновь не читающих тонну флуда)

Так а чем он лучше?

Быстрее?

запускается быстрее в разы

сам посуди близкий к процессору код уже больше похожий на машинный с инструкциями интерпретатору

либо сырой текстовый файл с раширением, для большого исходника разница огромная

Быстрее?

быстрее чего?

.py и запуска из консольки

сам посуди близкий к процессору код уже больше похожий на машинный с инструкциями интерпретатору

в питоне он ни капли не близок к процессорному

Единственный плюс .pyc - закрытые исходники

Если он все равно прогоняется через интерпритатор

Он же не на проце выполняется

Единственный плюс .pyc - закрытые исходники

чушь собачья

Единственный плюс .pyc - закрытые исходники

Так декомпилится вообще изи

С комментариями

.pyo вырезает комменты

С комментариями

.pyo уже нет

В последних версиях убрали

Для 2 есть

так, давайте по порядку

Он же не на проце выполняется

он минует стадию анализа кода на валидность

так как уже обработан процессором

процессор исполняет машинный код - набор байтиков в памяти, которые он считывает по очереди и выполняет базовые инструкции - операции с регистрами, ветвления, вот это всё

я еще застал эпоху когда приходилось вбивать циферками вот это всё 8)

процессор исполняет машинный код - набор байтиков в памяти, которые он считывает по очереди и выполняет базовые инструкции - операции с регистрами, ветвления, вот это всё

Это ясно mov eax,ebx Можно заменить байтами, в дебаггере вроде пишет

чтобы понимать происходящее был придуман ассемблер - это символьный язык, в котором опкодам процессора назначены текстовые мнемоники, но тем не менее этот язык практически остается один-в-один соответствующим машинным кодам

на разных архитектурах процессора pyc файл не исполнится*

pyc не зависит от архитектуры

на разных архитектурах процессора pyc файл не исполнится*

На разных питонах может и нет, на разных процессорах исполнится

да ну. вики вроде правду говорит

но писать на таком низком уровне достаточно утомительно, поэтому были разработаны более высокоуровневые языки - фортран, алгол, ада

чтобы перевести более человекопонятные тексты в машинный код было придумано несколько методов базовые - компиляция и интерпретация

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

компиляция же занималась трансляцией высокоуровневых команд в наборы машиных кодов напрямую, что давало очень высокую скорость исполнения

должно быть очевидно что в случае с интерпретацией достаточно портировать только интерпретатор на другой проц, но сами программы оставить как есть в случае с компиляцией, весь собранный код придётся компилировать заново под процессор с другой системой команд

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

в нем по сути были просто незаполненные поля для адресов переходов. и эту задачку решал линкер - он брал на входе набор этих полуфабрикатов и размещал их в памяти, заполняя уже финальными адресами пробелы

позднее появился гибридный вариант, p-code, он же байткод, когда вместо компиляции в нативные машинные коды, компиляция выполнялась в более абстрактную модель

так работали вижел бейсик, перл, жаба

бэйсик вообще раньше был некомпилируемым, помню

хз что ты помнишь, ибо их было дохера

и были и компилируемые и интерпретируемые варианты

частный случай, ибо их дохера

p-code/байткод - этот гибридный метод позволяет получать преимущества портабельности интерпретируемых языков - потому что код генерируется под универсальную абстракцию и преимущества компиляции - когда байткод можно либо очень быстро интерпретировать (JVM, питон и иже с ним), либо собрать из него нативный бинарник на лету (JIT, CLR), который будет работать на практически максимальной скорости

возвращаясь к pyc файлам

их состав предельно прост и не менялся с момента их появления. первые 4 байта - волшебный маркер версии 4 байта - отметка времени (os.path.gmtime), а дальше идёт сериализованный встроенным маршалером код объект

хорошо, любой байткод работает покуда есть интепретатор, это понятно, на всяком ли компьютере будет работать сам интерпретатор=) если взять какой нибудь частный случай процессора?

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

это дает солидную экономию времени для импорта

не зря спросил про байт-код :)

Хорошо, это понятно

Для библиотек полезно, для импорта

хорошо, любой байткод работает покуда есть интепретатор, это понятно, на всяком ли компьютере будет работать сам интерпретатор=) если взять какой нибудь частный случай процессора?

обычно байткоды дизайнят независимо от реальной архитектуры, что не мешает производителям железа реализовать потом эту абстракцию в реальном силиконе выходили java-процессоры, которые умеют напрямую выполнять байткод JVM. в ARM архитектуру в частности завезли расширения, которые позволяют такое делать на армах

А если скрипт одиночка? Будет ли прирост в скорости когда выполняется скрипт?

python script.py <--- это не импорт. для скриптов байткод не сохраняется и не ищется

тем не менее питон умеет запускать .pyc напрямую. ему просто пофиг

а в jython pyc файлов нет. там идёт трансляция исходников питона в ява-классы, после чего они компилируются в родной байткод и кэшируются как .class файлы

а в IronPython понятия байткода нет вовсе

а чо, разве в IL не компилируется?

в комплекте идёт тулза, которая перегоняет питоновые исходники в одну здоровую ассембли на clr

оно генерит его на лету

опциональная тулза позволяет сохранить как дллку

правда она достаточно убога пока что, и собирает в неё весь грёбаный стдлиб, либы и твой код

тем не менее питон умеет запускать .pyc напрямую. ему просто пофиг

Так быстрее запускать или медленнее?

ERROR: S client not available

разбить на ассембли ей низзя

Так быстрее запускать или медленнее?

я же писал

в крестах обджект файл так вообще просто огромный

Я думал ты про импорты писал

это побочный эффект шаблонизации

Типо импортит быстрее

ну да

я же писал что для скриптов байткод не сохраняется

Его можна сделать .pyc python -m compileall .

при python script.py питон на script.pyc смотреть не будет

хоть закомпиляйся

Ага, то-есть невозможно сделать так?

Бля я запутался

python script.pyc можно

Ну

И будет быстрее?

ты заебал

Чем если бы запускать python script.py

ручник с тормоза сними

?

будет, но в общем случае достаточно мало особенно если весь скрипт из import django; django.main()

или какойнить фигни в этом духе

Кстати А можно закомпилить весь проэкт джанго?

Будет быстрее?

бля... я пошел

в компаниях за скорость работы спросят=)

хинт: изя/пип при установке компилируют ёбаный проект полностью

ты б хоть раз заглянул бы в стдлиб или установленные пакеты в site-packages. вопрос бы отпал

хинт: изя/пип при установке компилируют ёбаный проект полностью

Для деплоя проектов юзают пип?

?

Я думал git clone python manage.py runserver ??????? Profit

ты продеплой не спрашивал же