Если Python интерпретируется, что такое файлы .pyc?
Чтобы показать номер страницы и общие страницы, вы можете использовать этот фрагмент javascript в нижнем колонтитуле или коде заголовка:
var pdfInfo = {};
var x = document.location.search.substring(1).split('&');
for (var i in x) { var z = x[i].split('=',2); pdfInfo[z[0]] = unescape(z[1]); }
function getPdfInfo() {
var page = pdfInfo.page || 1;
var pageCount = pdfInfo.topage || 1;
document.getElementById('pdfkit_page_current').textContent = page;
document.getElementById('pdfkit_page_count').textContent = pageCount;
}
И вызвать getPdfInfo со страницей onload
Конечно, pdfkit_page_current и pdfkit_page_count будут двумя элементами, отображающими числа.
Фрагмент, взятый из здесь
5 ответов
Они содержат байт-код , в который интерпретатор Python компилирует исходный код. Затем этот код выполняется виртуальной машиной Python.
Документация Python объясняет это определение следующим образом:
Python - это интерпретируемый язык, поскольку в отличие от скомпилированного, хотя различие может быть расплывчатым из-за наличие компилятора байт-кода. Это означает, что исходные файлы могут быть запускать напрямую без явного создание исполняемого файла, который затем бег.
Не существует такого понятия, как интерпретируемый язык. Используется ли интерпретатор или компилятор - это исключительно черта реализации и не имеет абсолютно никакого отношения к языку.
Каждый язык может быть реализован либо интерпретатором, либо компилятором. Подавляющее большинство языков имеют по крайней мере по одной реализации каждого типа. (Например, существуют интерпретаторы для C и C++ и компиляторы для JavaScript, PHP, Perl, Python и Ruby). Кроме того, большинство современных реализаций языка на самом деле сочетают в себе и интерпретатор, и компилятор (или даже несколько компиляторов).
Язык - это просто набор абстрактных математических правил. Интерпретатор - это одна из нескольких конкретных стратегий реализации языка. Эти два понятия живут на совершенно разных уровнях абстракции. Если бы английский был типизированным языком, термин "интерпретируемый язык" был бы ошибкой типа. Утверждение "Python - интерпретируемый язык" не просто ложно (поскольку ложность подразумевает, что утверждение имеет смысл, даже если оно неверно), оно просто не имеет смысла, потому что язык может никогда быть определен как "интерпретируемый". "
В частности, если вы посмотрите на существующие в настоящее время реализации Python, вот какие стратегии реализации они используют:
- IronPython: компилирует в DLR деревья, которые DLR затем компилирует в байткод CIL. Что происходит с байткодом CIL, зависит от того, на каком CLI VES вы работаете, но Microsoft .NET, GNU Portable.NET и Novell Mono в конечном итоге компилируют его в родной машинный код.
- Jython: интерпретирует исходный код Python, пока не определит горячие пути кода, которые затем компилирует в байткод JVML. То, что происходит с байткодом JVML, зависит от того, на какой JVM вы работаете. Maxine будет напрямую компилировать его в неоптимизированный родной код, пока не определит горячие пути кода, которые затем перекомпилирует в оптимизированный родной код. HotSpot сначала интерпретирует байткод JVML, а затем компилирует горячие пути кода в оптимизированный машинный код.
- PyPy: компилируется в байткод PyPy, который затем интерпретируется виртуальной машиной PyPy VM, пока она не определит пути горячего кода, который затем компилируется в родной код, байткод JVML или байткод CIL, в зависимости от платформы, на которой вы работаете.
- CPython: компилирует в байткод CPython, который затем интерпретирует.
- Stackless Python: компилируется в байткод CPython, который затем интерпретируется.
- Unladen Swallow: компилируется в байткод CPython, который затем интерпретируется до выявления горячих путей кода, которые затем компилируются в LLVM IR, который компилятор LLVM затем компилирует в родной машинный код.
- Cython: компилирует код Python в переносимый код C, который затем компилируется стандартным компилятором C
- Nuitka: компилирует код Python в машинно-зависимый код C++, который затем компилируется стандартным компилятором C
Вы можете заметить, что каждая из реализаций в этом списке (плюс некоторые другие, которые я не упомянул, например tinypy, Shedskin или Psyco) имеет компилятор. На самом деле, насколько мне известно, в настоящее время не существует ни одной интерпретируемой реализации Python, не существует и никогда не существовало такой реализации.
Мало того, что термин "интерпретируемый язык" не имеет смысла, даже если вы понимаете его как "язык с интерпретируемой реализацией", это явно не так. Тот, кто вам это сказал, явно не знает, о чем говорит.
В частности, файлы .pyc, которые вы видите, - это кэшированные файлы байткода, созданные CPython, Stackless Python или Unladen Swallow.
Они создаются интерпретатором Python при импорте файла .py и содержат «скомпилированный байт-код» импортированного модуля / программы, идея заключается в том, что «перевод» из исходного кода в байт-код (который нужно выполнить только один раз) можно пропустить при последующих import s, если .pyc новее, чем соответствующий файл .py , таким образом немного ускоряет запуск. Но это все еще интерпретируется.
Python (по крайней мере, наиболее распространенная его реализация) следует схеме компиляции исходного текста в байт-коды, а затем интерпретирует байт-коды на виртуальной машине. Это означает, что Python (опять же, в наиболее распространенной реализации) не является ни чистым интерпретатором, ни чистым компилятором.
Другой стороной этого является, однако, то, что процесс компиляции в основном скрыт - файлы .pyc в основном рассматриваются как кэш; они ускоряют работу, но вы обычно не должны знать о них вообще. Он автоматически аннулирует и перезагружает их (перекомпилирует исходный код), когда это необходимо, основываясь на метках времени/даты файла.
Единственный раз, когда я столкнулся с этой проблемой, это когда скомпилированный файл байткода каким-то образом получил временную метку далеко в будущем, что означало, что он всегда выглядел более новым, чем исходный файл. Поскольку он выглядел более новым, исходный файл никогда не перекомпилировался, поэтому, какие бы изменения вы ни вносили, они игнорировались...
Мне дали понять, что Python - интерпретируемый язык ...
Этот популярный мем неверен или, скорее, построен на неправильном понимании уровней (естественного) языка: аналогичной ошибкой было бы сказать, что «Библия - это книга в твердом переплете». Позвольте мне объяснить это сравнение ...
«Библия» - это «книга» в том смысле, что она представляет собой класс (реальных, физических объектов, идентифицированных как) книг; книги, обозначенные как «копии Библии», должны иметь нечто общее (содержание, хотя даже они могут быть на разных языках, с разными приемлемыми переводами, уровнями сносок и других аннотаций) - однако эти книги являются прекрасно разрешено отличаться по множеству аспектов, которые не считаются фундаментальными - тип переплета, цвет переплета, шрифт (ы), используемый в печати, иллюстрации, если таковые имеются, широкие поля для записи или нет, количество и виды встроенных закладок и т. д., и т. д.
Вполне возможно, что типичный типичный экземпляр Библии действительно будет в твердом переплете - в конце концов, это книга, которую обычно нужно читать снова и снова, с закладками в нескольких местах, пролистывать поиск заданных указателей на главы и стихи и т. д. и т. д., а хороший переплет в твердом переплете может продлить срок службы данной копии при таком использовании. Однако это мирские (практические) вопросы, которые нельзя использовать для определения того, является ли данный реальный книжный объект копией Библии: распечатки в мягкой обложке вполне возможны!
Точно так же Python - это «язык» в смысле определения класса языковых реализаций , которые все должны быть похожи в некоторых фундаментальных отношениях (синтаксис, большая часть семантики, за исключением тех частей, где им явно разрешено различаться), но они полностью могут различаться практически во всех деталях "реализации", включая то, как они работают с исходными файлами, которые им предоставлены, компилируют ли они источники в некоторые формы более низкого уровня (и, если да, то какую форму - и сохраняют ли они такие скомпилированные формы, на диск или в другое место), как они выполняют указанные формы и т. д.
Классическую реализацию CPython часто для краткости называют просто «Python» - но это всего лишь одна из нескольких реализаций производственного качества, наряду с Microsoft IronPython (который компилируется в коды CLR, то есть «.NET». ), Jython (который компилируется в коды JVM), PyPy (который написан на самом Python и может компилироваться в огромное количество «внутренних» форм, включая сгенерированный «точно в срок» машинный язык).Все они Python (== "реализации языка Python"), точно так же, как многие внешне разные книжные объекты могут быть Библиями (== "копиями Библии").
Если вас особенно интересует CPython: он компилирует исходные файлы в специфичную для Python форму нижнего уровня (известную как «байт-код»), делает это автоматически при необходимости (когда нет файла байт-кода, соответствующего источнику файл, или файл байт-кода старше исходного или скомпилирован другой версией Python) обычно сохраняет файлы байт-кода на диск (чтобы избежать их повторной компиляции в будущем). OTOH IronPython обычно компилируется в коды CLR (сохраняя их на диск или нет, в зависимости от) и Jython в коды JVM (сохраняя их на диск или нет - он будет использовать расширение .class , если оно сохранит их. ).
Эти формы нижнего уровня затем выполняются соответствующими «виртуальными машинами», также известными как «интерпретаторы» - виртуальной машиной CPython, средой выполнения .Net, виртуальной машиной Java (также известной как JVM), в зависимости от ситуации.
Итак, в этом смысле (что делают типичные реализации) Python является «интерпретируемым языком» тогда и только тогда, когда таковыми являются C # и Java: все они имеют типичную стратегию реализации: сначала создание байт-кода, а затем его выполнение через ВМ / переводчик.
Скорее всего, основное внимание уделяется тому, насколько «тяжелым», медленным и сложным является процесс компиляции.CPython спроектирован так, чтобы компилировать как можно быстрее, легче, насколько это возможно, с минимальными церемониями - компилятор очень мало проверяет ошибки и оптимизирует их, поэтому он может работать быстро и с небольшим объемом памяти, что, в свою очередь, позволяет ему запускаться автоматически и прозрачно, когда это необходимо, при этом пользователю даже не нужно знать, что в большинстве случаев происходит компиляция. Java и C # обычно принимают больше работы во время компиляции (и поэтому не выполняют автоматическую компиляцию), чтобы более тщательно проверять ошибки и выполнять больше оптимизаций. Это континуум серых шкал, а не ситуация черного или белого, и было бы совершенно произвольно устанавливать порог на некотором заданном уровне и говорить, что только выше этого уровня вы называете это «компиляцией»! -)