Python — интерпретируемый

Чиво-чиво?

Python — интерпретируемый

Чиво-чиво?

ну-ка, рассмеши пацанов, какой он по-твоему?

Покажи мне компилятор питона в машинный код.

ну-ка, рассмеши пацанов, какой он по-твоему?

CPython - компилятор в байткод. А у пацанов мелочь-то есть?

Покажи мне компилятор питона в машинный код.

Компилятор обязательно в машкод? А пацаны срайона не засмеют?

Ну я имел в виду именно в машинный.

байткод

Байткод это не серьезно.
Под компилируемым языком прежде всего подразумевается в машкод.

List of programming languages by type:
Compiled languages
Interpreted languages

http://ompldr.org/vOW1nZg

байткод

Байткод это не серьезно.

Python - компилятор, серьезно это или нет - решать тебе.

Ага, languaged.

Во-певрых, ссылку на статью уже привели. Во-вторых, повторю, что я имел в виду компиляцию именно в машинный код. Так вот, Python из-за его особенностей скомпилировать в машинный код затруднительно, если не невозможно. А Go, насколько я знаю, разрабатывается как раз для компиляции в машинный код.

CPython - компилятор в байткод.

Байт-код интерпретируется. То как питон программу исполняет - построчно или через промежуточное представление не очень то и важно. Всё равно это интерпретатор.

А, не, оказалось, это группа создателей комедийного сериала http://en.wikipedia.org/wiki/Monty_Python's_Flying_Circus

Но полюбому удавы не при делах (как, впрочем, и гитаристы).

Python - компилятор

А я думал что Python - язык программирования.

Нет. shd - чтобы интерпретатор был демоном и скрипты были бинарными

Ну я имел в виду именно в машинный.

Что такое «машинный код»? Байткод JVM на x86 не машинный? А на Java-процессорах? А если завтра «Python-процессор» сделают?

А код x86, работающий в виртуалке на ARM — он какой?

А код x86, который на современных x86 процессорах на лету транслируется во внутреннее представление — это, кстати, интерпретация.

...

Классический Python на x86 — это компилятор в байткод + интерпретатор байткода на уровне виртуальной машины. (JIT, как я понимаю, только в PyPy есть?). Про такие языки нельзя сказать однозначно «компилятор» или «интерпретатор» даже в указании конкретной реализации.

Ещё Java назовите интерпретатором :D

Ну и ни один язык нельзя классифицировать с этой точки зрения без указания реализации. Скажем, есть интерпретирующие версии Си.

http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

Яйцеголовый теоретик получил то, что он заслуживает.

Я это говорил лет пять назад - педон не нужен для реального программирования.

Только Java является универсальным «lingua franca nova» для практического программирования. Google GWT и Google Android тому примеры.

Кульхацкеры-борцуны с enterpriZe в очередной раз облажались.

Теперь пускай они грызут монитор и повторяют ритуальные мантры о зловредности enterpriZe и бездуховности общества потребления.

оказалось, это группа создателей комедийного сериала http://en.wikipedia.org/wiki/Monty_Python's_Flying_Circus

внезапно, да?

удавы не при делах

man Искандер

Мне кажется, они просто раньше писали на питоне то, что надо было сразу писать на C/C++, а теперь переписывают это на Go.

Обзываешься.

Python - компилятор, серьезно это или нет - решать тебе.

Фаза компиляции есть во всех современных интерпритаторах, поэтому грань зыбкая, но СPython принято считать интерпритатором.

Ты ксати видел что в pyc файлах? Он даже комменты от туда не удаляет, если не включить более жесткий вариант. Это просто подготовка к интерпритации, а не перевод в другую систему комманд.

Только Java

Java

Java

Linus Torvalds: Java A Horrible Language

Классический Python на x86 — это компилятор в байткод + интерпретатор байткода на уровне виртуальной машины ... Про такие языки нельзя сказать однозначно «компилятор» или «интерпретатор» даже в указании конкретной реализации.

Тогда и чистый интерпретатор можно назвать компилятором. Построчным. CPython - это интерпретатор (байт-кода), совершенно однозначно. Для чего мы выполняем команду python foo.py? Чтобы получить выхлоп в виде байт-кода? Нет же, для интерпретации скрипта. Сохраненный foo.pyc - это не более чем кэшированное промежуточное представление, побочный эффект работы интерпретатора.

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

сотни проектов типа dropbox работают на нём и рубят миллионы.

И это не делает его лучше или хуже.

Я нигде не говорил, что он говно. Вроде даже наоборот (но не здесь).

А dropbox не нужен, пока не сделают возможность примонтировать свой раздел и пользоваться как локальной ФС.

А dropbox не нужен, пока не сделают возможность примонтировать свой раздел и пользоваться как локальной ФС.

Тем не менее, это самый адекватный и дружественный к пользователю сервис подобного рода.

Ну никто не отрицал, что питон там только для прототипирования и потом под релиз все переписывают.

Ну никто не отрицал, что питон там только для прототипирования

Нет смысла отрицать то, что никто не утверждал (ты не в счет).

А он уже и свой говноязычок придумал?

Компилируемый в QR-коды. %)

Какая разница хороший или плохой , бабло приносит и ладно.

Нужно монтирование юзай яндекс диск.

Байткод JVM на x86 не машинный?

Он не содержит инструкций, специфичных для x86, значит нет.

А на Java-процессорах?

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

А если завтра «Python-процессор» сделают?

Вот в этом я сомневаюсь. Ну сделают, но это будет что-то типа SoC с запущенным на нём интерпретатором.

А код x86, работающий в виртуалке на ARM — он какой?

Тормознутый.

А код x86, который на современных x86 процессорах на лету транслируется во внутреннее представление — это, кстати, интерпретация.

Возможно (тонкости не знаю), но он привязан к конкретной архитектуре. На других архитектурах будет работать с существенной потерей производительности.

Скажем, есть интерпретирующие версии Си.

Ты имеешь в виду диалекты? Но сам «настоящий» C (C99, C11) не очень для этого подходит. Обычно для интерпретации программы интерпретатором открывают файл исходного кода, с которого начинается выполнение программы. В C же это не прокатит, т.к. он не содержит информацию о других файлах с исходниками данного проекта и о требуемых сторонних библиотеках, которые можно подключить. Если только Makefile открывать интерпретатором.

Скорее всего. Прототипы высоко нагруженных приложений писать на Python можно, но потом всё равно нужно переписывать всё на C/C++/Java или другой компилируемый ЯП. Скриптовые языки не предназначены для таких задач. Тот же facebook создал свой компилятор для PHP не зря... Знали бы они, на сколько прийдётся массштабировать свои приложения, с самого начала выбрали бы другой ЯП.

Тогда и чистый интерпретатор можно назвать компилятором

Ни разу. Компилятор от интерпретатора отличается тем, что второй транслирует код токен за токеном, а первый — транслирует в иное представление (как правило более быстрое) и исполняет его целиком.

Особенно явное отличие — в исполнении циклов. Интерпретатор тело цикла транслирует на каждом проходе. Компилятор — только один раз. Когда-то это было типичным примером их отличия. Но сейчас теория и классификация мало кого интересуют.

Он не содержит инструкций, специфичных для x86, значит нет.

Ок. Так и запишем — код x86 не машинный, если исполняется в виртуалке под ARM.

Возможно (тонкости не знаю)

Вот в этом-то всё и дело. Классификация крайне простая, но некоторые, прибитые гвоздями к x86 и конкретным версиям компиляторов начинают плодить кривые сущности.

Ок. Так и запишем — код x86 не машинный, если исполняется в виртуалке под ARM.

Он машинный для другой машины. А когда ставится задача собрать в машинный код, то имеется в виду код именно для той машины, на которой его будут запускать. А у байт-кода Python нет машины, для которой он был бы нативным.

Он машинный для другой машины.

Соответственно, такая классификация получается релативной и теряет общий смысл.

А у байт-кода Python нет машины, для которой он был бы нативным.

Если при появлении новой машины старый продукт поменяет статус, то такая классификация, опять же, имеет мало смысла.

Но вне зависимости от теоретизирования, сейчас язык Go можно собрать в машинный код для распространённых на рынке платформ, а Python — нет. Следовательно, у программы на Go теоретически (а скорее всего и практически) производительность на большинстве современных платформ будет выше. Но в то же время (по крайней мере если судить субъетивно) Python позволяет затрачивать меньше времени на написание программы. Следовательно, данные языки не взаимозаменяемы. Это собственно то, что я хотел сказать, когда отвечал на заявление, что гуглу питон не нужен, т.к. у них есть «свой питон» — go.

Но вне зависимости от теоретизирования

По этому поводу возражений никаких. Спор касался только утверждения «Python — интерпретируемый». Оно неверно с любой стороны.

СPython принято считать интерпритатором

Эту тему на каком-то из вселенских соборов задвигали? Кем принято? И кроме cpython у нас еще есть pypy, если что.

Эту тему на каком-то из вселенских соборов задвигали? Кем принято?

Чего нервничаешь то?

А он уже и свой говноязычок придумал?

Мощь юнитов systemd ограничена только количеством инод в твоей ФС :)

Ты ксати видел что в pyc файлах? Он даже комменты от туда не удаляет, если не включить более жесткий вариант. Это просто подготовка к интерпритации, а не перевод в другую систему комманд.

Это не так. Не удаляет комментарии он, потому что в питоне принято писать самодокументирующийся код, т.е. можно документацию посмотреть у скомпилированного модуля.