Pymothoa — новый JIT-компилятор для Python

Tested with LLVM 3.1 (may also work for other version).

И? Каким образом Python-код становится «невалидным для остальных» - появляются функция var и пара пакетов? Ты же знаешь - поделись с нами.

Pyrex, не?

Да блин. Я понимаю, читать весь топик лень, но Pyrex устарел же - вместо него Cython давно %)

:-) Да, я уже посмотрел, что он сдох.

«И так будет со всяким!..»

«И так будет со всяким!..»

Да, мы все умрем :/

Pymothoa расширяет возможности Python с помощью JIT без модификации кода интерпретатора.

Сплошное 4.2: думал, что это что-то вроде psyco, обрадовался. А оказалось, что изобрели очередной аЦетон, причем ущербный.

Сплошное 4.2: думал, что это что-то вроде psyco, обрадовался. А оказалось, что изобрели очередной аЦетон, причем ущербный.

а где код интерпретатора изменяется?

Как будто это печальная новость :)

Но вообще я уже посмотрел на cython. Вполне себе нормальный наследник пайрекса. Топик выглядит ненужным велосипедом. Я понимаю, что в мире дофига соискателей Bachelor degree in CS, но как-то себя сдерживать-то надо! :)

я уже посмотрел на cython. Вполне себе нормальный наследник пайрекса. Топик выглядит ненужным велосипедом.

Ты смотрел невнимательно.

Я понимаю, что в мире дофига соискателей Bachelor degree in CS

Если здесь и есть Bachelor degree, то в SE.

А в чём подвох?

А в чём подвох?

В смысле?

Если здесь и есть Bachelor degree, то в SE.

Ой, да ладно! В мои обязанности входит отсмотр резюмов. Чего там только ни бывает в качестве дипломных работ :)

а где код интерпретатора изменяется?

И как этот вопрос относится к тому, о чем я написал выше?

В смысле?

В смысле,

...я уже посмотрел на cython. Вполне себе нормальный наследник пайрекса...

Ты смотрел невнимательно.

Из чего я делаю вывод, что cython не является нормальным наследником пайрекса (который для своих задач был вполне пригоден), и требуются какие-то альтернативы

Интересуюсь, почему.

Из чего я делаю вывод, что cython не является нормальным наследником пайрекса (который для своих задач был вполне пригоден)

Я даже не стану гадать, что заставило тебя сделать такой вывод из моих слов.

и требуются какие-то альтернативы

(уныло) Кроме меня и xpahos, в этом топике хоть кто-нибудь посмотрел код? Если я правильно понимаю, эта хрень - пример метапрограммирования на Python - она берет AST, генерируемый компилятором, транслирует его LLVM'ом и вызывает через ctypes. Ты уверен, что это альтернатива Cython? Как по мне, это просто другой инструмент.

Метапрограммирование, инновации, Сколково....

Его расширения синтаксиса - это просто неосиляторство автора данного поделия. К слову сказать, shedskin не требует явно указывать типы - он их сам вычислит. Для переменной тип вычисляется по первому присвоению, причём потом тип переменной можно переназначить тем же присвоением, что и реализовано в shedskin. Для функции тип вычисляется по всем операторам return/yield или по их отсутствию, если несколько return'ов создают неоднозначность - shedskin выдаст предупреждение, что конструкция проигнорирована (как и все statement'ы, её использующие).

Автор не осилил вывод типов и, видимо, думает, что кто-то станет переписывать скрипты, чтобы увидеть, что делать этого оказывается не стоило, т.к. pypy/shedskin оптимизируют лучше.

Его расширения синтаксиса - это просто неосиляторство автора данного поделия.

Ты пока не проявил достаточно компетентности, чтобы делать такие выводы.

shedskin не требует явно указывать типы - он их сам вычислит

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

Видишь, в чём беда. От добра добра не ищут.

Если хреновина лает как собака 1) вводит новый DSL (через декораторы или напрямую - непринципиально) 2) используя этот DSL ускоряет требуемые куски путём скармливания их генератору нативного кода; - то какая разница, как оно внутри устроено. Это все равно уже не Джонни не Питон, а некоторый другой язык, несовместимый с исходным.

Видишь, в чём беда. От добра добра не ищут.

То есть, «if it ain't broken - don't fix it»? Достойный принцип, но вроде никто не предлагал немедленно переписывать Cython-код, или я что-то упустил?

используя этот DSL ускоряет требуемые куски путём скармливания их генератору нативного кода; - то какая разница, как оно внутри устроено

Ну, если тебе нет разницы, ОК. Тебе эта штука не будет нужна, даже если ее доведут до ума. Будешь писать Cython-модули вместо аннотаций.

Это все равно уже не Джонни не Питон

Глубоко философский вопрос. Я вот очень хотел бы Python со статической типизацией (не такой, конечно, как в сабже, а нормальной).

Тебе эта штука не будет нужна, даже если ее доведут до ума.

Ых, дело не в том, доведут её до ума или нет. Просто это, э-э-э, дробление усилий. Ты вот можешь себе представить её в «основном» питоньем дереве? А в ситоньем? А в PyPy-шном? А что она все эти _альтернативные_ и, в целом, несовместимые решения зарулит?

«Билл Гейтс однажды заметил, с нетипичным для него цинизмом, как сделать программу дружелюбной к пользователю: изготовить печать и поставить на каждой коробке штамп «USER FRIENDLY». Компьютерная индустрия взяла его метод на вооружение.» (с) Алан Купер

Shedskin вычисляет тип настолько, насколько возможно без совсем уж замороченной эвристики типа «тут параметр функции a всегда попадает в интервал [42..54], а, значит, ветка return 0 никогда не будет выполнена и тип однозначен». Умеет сводить к базовому классу, если class A, class B(A) и функция возвращает как A, так и B.

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

Просто это, э-э-э, дробление усилий.

Чьих?

Ты вот можешь себе представить её в «основном» питоньем дереве?

Ых, да весь пойнт этой штуки в том, что интеграция ее в «основное» дерево требует минимальных усилий (написано же - «adding JIT compilation without any modification of the interpreter source code», «lives at the application level»). Это обычный библиотечный модуль, capiche? Его даже интегрировать не обязательно.

она все эти _альтернативные_ и, в целом, несовместимые решения зарулит?

Я вот не знаю даже, взлетит ли PyPy. Базовая идея сабжа мне очень нравится, что из него получится - ХЗ. Сейчас он наверняка проигрывает тому же numpy.

Shedskin вычисляет тип настолько, насколько возможно

Так вот, не всегда возможно вычислить то, что нужно. И алгоритм вычисления иногда зацикливается (и, ЕМНИП, это его неотъемлимое свойство).

А вы просто берёте поделку, ничего не умеющую, и зачем-то защищаете её.

И это плохо... чем именно?

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

Ну, тебя я и не собирался спрашивать о том, что именно заставило тебя так понять мои слова.

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

Кстати... ты так и не ответил мне:

tailgunner> Каким образом Python-код становится «невалидным для остальных» - появляются функция var и пара пакетов?

С numpy не встречался, по ссылке читать день, но http://morepypy.blogspot.com/2012/04/numpy-on-pypy-progress-report.html

*лень

Спасибо, я тоже читаю morepypy.

Это обычный библиотечный модуль, capiche? Его даже интегрировать не обязательно.

Его обязательно интегрировать. Просто для того, чтобы однозначно отвечать на вопрос: «У меня программа на пейтоне тормозит! Что делать, куды бечь?!». Это, собственно, не технический даже, а организационный вопрос.

Его обязательно интегрировать

Тот же psyco не интегрировали, однако все знают, где его взять и как использовать.

Хых, «Psyco is unmaintained and dead.» Я бы не назвал это «однозначным ответом» на сформулированный мной вопрос. Хотя, конечно, смотря с какой стороны посмотреть на однозначность ;)

Вообще, критерием известности и «однозначности» в данном случае является поддержка/использование со стороны больших фреймворков и/или серверов приложений типа джанги.

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

Хых, «Psyco is unmaintained and dead.»

Внезапно, да? :) Но, тем не менее, его используют.

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

До этого далеко даже PyPy, куда более зрелому проекту. Ну и сам стиль использования сабжа намекает, что «поддержка в Django» для него не приоритет.

Использовать-то можно. Только вот на «Питон? Это такой тормозной язычок с придурошным синтаксисом для наколеночных трёхстрочников? Но и там лучше использовать Перл» не надо обижаться.

на «Питон? Это такой тормозной язычок с придурошным синтаксисом для наколеночных трёхстрочников? Но и там лучше использовать Перл» не надо обижаться.

Заметь, что, даже если решить проблему скорости, претензии к «придурошному синтаксису» останутся, так что... правильный ответ на приведенную фразу - спокойное «ПНХ» (можно не вслух, если это заказчик, который платит большое бабло %)).

Видишь, синтаксис - это, э-э-э, дело привычки. Если это единственная [значимая] проблема - то, считай, её и нет вовсе. Зря, что-ли, хор «ужасающихся пробелам, как способу выделения структурных блоков» подзатих. А вот отсутствие общего кодегайда по животрепещущим вопросам «нужно XYZ? делай раз, делай два, делай три» - это гораздо серьёзнее.

Из-за этого в своё время перловое ООП так толком и не взлетело. То есть, всё необходимое на уровне кубиков там, как минимум, с 5.0 присутствует. Однако, отсутствие «ясного пути» порождало таких несовместимых друг с другом монстров в пределах соседних модулей, что нах-нах. Потом-то, где-то к 5.6-5.8 они пришли к каким-то организационным договорённостям, как должно выглядеть наследование в обычных случаях, как оформлять эксепшны и прочее. И на CPAN, замечу, повалили модули, которые написаны с учётом этих договорённостей. Но поезд, в целом, к тому моменту уже ушёл.

отсутствие общего кодегайда по животрепещущим вопросам «нужно XYZ? делай раз, делай два, делай три» - это гораздо серьёзнее.

И каково значение (набор значений) XYZ?

Ну скорость работы-то всегда всплывает на том или ином этапе. Ну, конечно, если это не трёхстрочечная наколенщина.

Ну а что говорит, например, Си кодгайд по этому поводу? Полагаю, «используйте профайлер, чтобы найти узкие места, и меняйте алгоритм/меняйте структуры данных/на крайняк переписывайте на ассемблере»? В Питоне всё так же, только вместо ассемблера - Си.

Я вот очень хотел бы Python со статической типизацией

Boo тебе в руки.

Boo тебе в руки.

Ты правда думаешь, что я не знаю о Boo, Cobra, Groovy, whatever? Я использую Python, потому что всё остальное тупо не подходит.

P.S. мертвые архивы намекают.

Ты правда думаешь, что я не знаю

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

Ты правда думаешь, что я буду детально изучать регистранта с его архиами

Нет, конечно. Ты сунешь в ответ первое же название, которое нашел в гугле.

Ты сунешь в ответ первое же название, которое нашел в гугле.

Перестань уже проецировать свои мысли/поступки на других. Прям как маленький.

Ты сунешь в ответ первое же название, которое нашел в гугле.

Перестань уже проецировать свои мысли/поступки на других.

Я пока что не советовал другим, какие языки использовать. А что, ты реальный пользователь Boo?

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

А я и не утверждал, что нужно делать только так, просто написал, что есть вариант в виде Boo со статической типизацией.

А что, ты реальный пользователь Boo?

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

Pymothoa - это средство обойтись вообще без нативных модулей при сохранении приемлимого быстродействия. Если ты не понимаешь этого, бросай программирование и играй в футбол или теннис.

Это пока никакое не средство. Прогрев такой JIT будет неприятным и непонятным в больших проектах.

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

Без вас не получается.

Слишком много ошибок в слове Лисп.

новый JIT-компилятор для Python

новый

В английском языке для таких случаев есть удобное устоявшееся выражение «yet another ...».

пока Cython не станет Ъ-компилятором, со всем «умностями» настоящих компиляторов, он в принципе проигрывает LLVM

Пока г%вно не станет Ъ-лопатой, им в принципе будет трудно копать землю.

Пока г%вно не станет Ъ-лопатой, им в принципе будет трудно копать землю.

Будь тоньше, и люди к тебе потянутся.