> Почему до сих пор не существует компилятора для питона?

Их существует несколько. Правда, это не компиляторы в нативный код.

> Ведь отличный же язык, если гипотетический компилятор оптимизировать до сопоставимости скорости выполнения приложений с С/С++

Это невозможно. Питон - динамический язык, его _очень_ трудно оптимизировать на этапе компиляции.

Но работа идет :) http://morepypy.blogspot.com

а, простите, что такое динамический язык?

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

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

 >>> a = 4
 >>> b = 'f'
 >>> a+b
 Traceback (most recent call last): File "<stdin>", line 1, in <module> 
 TypeError: unsupported operand type(s) for +: 'int' and 'str'
 >>> 

компилятор гипотетически легко может выяснить типы a и b, но этого не делается, т.к. иначе не быдет «утиной типизации»: оперирование объектами по интерфейсу (Если что-то ходит, как утка, и крякает, как утка, то это, должно быть, утка»).

хотя причинно-следственных связей между утками и динамичностью не докажу :)

а почему утиную типизацию нельзя реализовать compile time? вывод типов, параметрический полиморфизм нельзя ко всему этому прикрутить?

> а почему утиную типизацию нельзя реализовать compile time? вывод типов, параметрический полиморфизм нельзя ко всему этому прикрутить?

можно, называется лисп. И быстрее он питона в разы.

> Это невозможно. Питон - динамический язык, его _очень_ трудно оптимизировать на этапе компиляции.

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

> хотя причинно-следственных связей между утками и динамичностью не докажу :)

Ну вроде как в статически типизированном языке утиной типизации быть не может :).

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

Есть (неправильная) точка зрения, что динамическая типизация - это когда тип связан со значением переменной, а статическая - с именем переменной (самой переменной).

> типы переменных не задаются явно.

в Haskell они тоже могут не задаваться явно :) могут даже не задаваться вообще в некоторых простых программах.

> сейчас гугл работает над питономашиной - должно получиться нечто похожее на явамашину со всеми вытекающими - и скоростью в том числе.

А ссылку можно? МНе почему-то кажется, что сильно быстрее не будет, ибо динамическая типизация, а у явы - статическая.

>вывод типов, параметрический полиморфизм нельзя ко всему этому прикрутить?

самому интересно. http://www.artima.com/weblogs/viewpost.jsp?thread=86641 и http://groups.google.com/group/comp.lang.python/msg/114a25d394769591 вроде как намекают, а результата не видно. кто-нибудь просветите, чем кончилось?

>а почему утиную типизацию нельзя реализовать compile time?

потому что объекты могут изменяться в run-time, в чем и профит? // К.О.

есть же psyco. но он не компилятор а этот, как его, just-in-type specializer, во http://psyco.sourceforge.net/psyco-pepm-a.ps.gz

*just-in-time

>ведь не так уж и сложно реализовать, имхо, команда человек из 10 за полгода бы справилась.

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

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

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

имхо питон вполне быстрый.
у него отличная интеграция с си - какие-то критичные куски можно всегда вынести в расширение на си. можно дергать сишные библиотеки через ctypes.
если не нравится писать на си - есть pyrex.
для некоторых вещей ещё есть, например, numpy.

>а почему утиную типизацию нельзя реализовать compile time?

вотому что "утиность" характеризуется поведением сущности, а не внешним видом. если ты и так видишь, что перед тобой утка - зачем сношать мозг?

а вывод типов - он всё-таки полный тип выводит, а не класс типов

Питон - слишком динамический язык. Его семантика прямо противоречит возможности эффективной статической компиляции (например, нельзя локальные переменные перенести в регистры - потому что существует возможность изменить их непонятно откуда). Но тем не менее, теоретически, во многих случаях можно получать хорошо скомпилированный (но в рантайме, т.е., JIT) код. Например, для lua есть trace compiler.

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

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

Лисп составит конкуренцию на всех задачах.

>ведь не так уж и сложно реализовать, имхо, команда человек из 10 за полгода бы справилась.

ха-ха

Есть такой "компилятор". Называется pypy, только чтоб им что-то собрать трахаться надо долго.

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

К сожалению в нем нет ничего отличного. Просто бывает удобен, не более того.

Есть гораздо более интересные языки. Например Haskell (питонячий list comprehension взят от туда). Там не динамическая типизация, а динамичский полиморфизм, т.е. компилятор на стадии компиляции подбирает переменным полходящие типы и оптимизирует. Скорость программ близка к С++. Есть еще похожий на него OCaml.

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

http://habrahabr.ru/blogs/google/55782/

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

>> Это невозможно. Питон - динамический язык, его _очень_ трудно оптимизировать на этапе компиляции.

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

Если добавить в Питон объявения типов, это будет уже не Питон.

> Если добавить в Питон объявения типов, это будет уже не Питон.

А если сделать их опциональными, то это будет все еще Питон. Ваш К.О.

>> Если добавить в Питон объявения типов, это будет уже не Питон.

> А если сделать их опциональными, то это будет все еще Питон. Ваш К.О.

Теперь, Капитан, придумайте, как статический чекер будет проверять вызовы getattr :)

> Теперь, Капитан, придумайте, как статический чекер будет проверять вызовы getattr :)

никак. Там где он сможет соптимизировать - соптимизирует, там где не сможет - оставит как есть.

>> Теперь, Капитан, придумайте, как статический чекер будет проверять вызовы getattr :)

> никак. Там где он сможет соптимизировать - соптимизирует, там где не сможет - оставит как есть.

Ну то есть полностью статическая компиляция/оптимизация невозможны в принципе. Ну а за кое-каким описанием практических трудностей статической компиляции Питона - в гугль. Например, Shed Skin, PyPy. Если найдешь материалы по Starkiller - отпишись сюда :)

Как-как... херово :) Это естественно накладывает ограничение на код. Ибо скорее всего в принципе невозможно придумать статическую систему типов, которая будет изоморфна существующей.

> Как-как... херово :) Это естественно накладывает ограничение на код

Вот поэтому сабжевый компилятор невозможен для полного Питона. Для RPython - вероятно.

в лиспе тоже динамическая типизация

я не знаю питон, но какой смысл менять тип рантайм?

ну вывод классов

> команда человек из 10 за полгода бы справилась.

Даже интерпретатор достаточно нетривиально устроен(который уже лет 15 допиливают) а уж компилятор скока делать...

> сопоставимости скорости выполнения приложений с С/С++

Это практически невозможно из-за того что язык динамический. Если нужна скорость то часто помогает переписывание критичных к скорости модулей на C. Кстати, есть boa. Вполне возможно что к нему можно сделать компилер :)

>ну вывод классов

получится статический полиморфизм в духе C++. зачем?

> получится статический полиморфизм в духе C++. зачем?

Затем, что статический. Но даже он не получится.

> Почему до сих пор не существует компилятора для питона? ведь не так уж и сложно реализовать, имхо, команда человек из 10 за полгода бы справилась.

Отличная шутка! Вспомним, сколько лет продолжались мучительные роды пэррота, а результат никакущий. PyPy тоже в тупике, хотя средств и сил в него вбухали даже поболе. "3x faster than CPython" - это слёзы. Короче говоря, динамические языки ничто уже не спасёт. Cмотреть нужно в сторону современных статически типизированных языков: Boo, F#(.Net) или Scala(JVM). Для красноглазиков - Haskell или OCaml.

> PyPy тоже в тупике

Он только становится на крыло. "Since the blog post, here are the updated numbers: we run richards.py in 2.10 seconds (almost 4x faster than CPython), and only spend 0.916 seconds actually running the assembler (almost 9x faster than CPython)".

> Короче говоря, динамические языки ничто уже не спасёт

Ненавижу динамические языки, но сколько чисто статическую Яву доводили до ума - лет 10?

> Ненавижу динамические языки, но сколько чисто статическую Яву доводили до ума - лет 10

То то и оно. Причем JVM - это результат больших капиталовложений в труд высококвалифицированных full-time девелоперов. А pypy? Несколько исследователей работают за гранты, так? Parrot - вообще базар на чистом энтузиазме. И сколько тогда ждать приличных результатов? Лет 20? Разве что у гуглей выйдет что-то путное с ласточкой. Но зачем оно всё надо, если уже есть (почти) готовая для продакшна Scala на вылизанной платформе.

> А pypy? Несколько исследователей работают за гранты, так?

Примерно так. Ну и что? Питон уже сейчас используется и на сервере, и на клиенте. Если PyPy выдаст на-гора интерпретатор, который в несколько раз быстрее, то Питон укрепится там, где он есть, и пробьется новые ниши.

> Но зачем оно всё надо, если уже есть (почти) готовая для продакшна Scala на вылизанной платформе.

Ява закрепилась только на ынтерпрайзных серверах... Если твой продакшн нацелен туда, прекрасно.

>Но зачем оно всё надо, если уже есть (почти) готовая для продакшна Scala на вылизанной платформе.

scala слишком сложна для среднего девелопера.
groovy/grails для веба гораздо проще и удобнее.

>Почему до сих пор не существует компилятора для питона?

Классический Python - компилятор.

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

Да, а если нужна компиляция в нативный код - то, пожалуйста, Boo + .NET/Mono JIT: http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

Сказано же было - хочешь не писать типы и при этом компилять в натив - бери Haskell.

> Сказано же было - хочешь не писать типы и при этом компилять в натив - бери Haskell.

А как связаны наличие компилятора в нативный код и type inference?

Лисп лучше Питона во всех отношениях, кроме базового синтаксиса. Не хватает нормального приоритета операций и нотации a.b . Если бы это было, не возникли бы ни Ява, ни Питон.

> Лисп лучше Питона во всех отношениях, кроме базового синтаксиса. Не хватает нормального приоритета операций и нотации a.b . Если бы это было, не возникли бы ни Ява, ни Питон.

Я так понимаю переход с лиспа на питона провалился? :)

Похоже на то )) Я уже не верил в успех, но мой напарник согласился использовать лисп, что и решило вопрос. Действительно, тесты быстродействия питона раздражают. Питон не является полноценной динамической средой, в отличие от лиспа. Также в нём плохо поддерживается ФП, причём, ограничения выглядят совершенно нелепыми.
И в нём нет макросов.

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

Кроме того, я неплохо выдрессировал лисп. Например, теперь я могу вводить SQL запрос в подсказке лиспа вот так:

> fse * from my_table where ::(calculate-where-clause);

здесь calculate-where-clause - это функция лиспа. Предыдущие попытки
создать удобный интерфейс лиспа к SQL были не особо удачны. Впрочим, и этот вариант пока не идеален, но хотя бы понятно, как его доработать.

И я могу вводить дату вот так:

> dat1:2009-10-01

Также я в кои-то веки поставил ltk и могу видеть результаты своих SQL-запросов в табличном виде, а не в виде списков, что было неудобно. Впрочем tktable пока что нормально выдрессировать не удалось и работа с ней сильно уступает по удобству более "взрослым" GUI библиотекам.

Но, в общем-то, на данный момент проделанная работа снимает большинство неприятных моментов лиспа, а с остальными понятно что делать. Касаемо библиотек - да, в лиспе их относительно мало, но зато не так трудно привязывать новые библиотеки, написанные на C.

> Но, в общем-то, на данный момент проделанная работа снимает большинство неприятных моментов лиспа, а с остальными понятно что делать.

Нам ждать cl-fix v.2?

Угу, ждать. Наверное, всё же заведу проект на common-lisp.net.

Есть несколько языков, похожих на Питон до опупения по синтаксису, но не являющихся им в широком смысле:
1. Genie, из Vala. Синтаксис питоновый, семантика GObject. Если Vala -- это синтаксический сахар "C# для GObject", Genie -- это "Python для GObject".
2. Deelight, на языке D: http://delight.sourceforge.net/compare.html . Также для D есть биндинги, более удобные, чем для C: http://pyd.dsource.org/celerid.html и http://pyd.dsource.org/ , презентация http://pyd.dsource.org/dconf2007/presentation.html . В общем-то почти как на Си, только используется метапрограммирование в Ди на полную катушку.
3. Питоноподобный синтаксис для лиспа, см. I-expressions http://srfi.schemers.org/srfi-49/srfi-49.html или Sweet expressions http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html

Sweet expressions это довольно полная попытка прикрутить к лиспу обычный синтаксис. Хотя Common Lisp FAQ негодуэ осуждает изобретателей альтернативных синтаксисов, вам лично никто не мешает его использовать.
Common Lisp или там Factor (функциональный форт) -- это 2 языка построенных вокруг идеи homoiconicity, но это не значит, что к ним нельзя прикрутить более нормальный синтаксис. Например, Dylan -- это попытка прикрутить алг-ололо-подобный синтаксис, при этом сохранив это свойство homoiconicity: см. статью про Dexprs -- там они заявляют, что для макросов более удобным является не AST, а SST (Skeleton Syntax Tree), обобщение где узел -- не токен, а класс токенов, а макросы могут проверять тип узлов, например выражение или блок или идентификатор.

Эти все 3 языка не питон, но чтото подобное. Под ними не заработает waf scons и т.п. без допиливания, но если допилить, заменит классический питон с лихвой.
Итого, что имеем из плюсов классического питона: декораторы и батарейки. Допилите их для 1..3 -- и они вполне себе заменят классический питон.

Sweet expressions

например, тут http://www.dwheeler.com/readable/version02.html см в качестве примеров BitC, GCC RTL, NewLisp etc. Напишите поверх этого сахара макросов, и вот вам -- компилируемый с помощью GCC "псевдопитон".