Comments 94
PyPy он потому что Python интерпретатор написанный на самом Python.
Ну по идее это обычный Python. То есть просто вместо python manage.py запускаете pypy manage.py, а уж как Вы там его до этого цепляли — так и цепляйте.
не все так просто — тут уже процитировали, что пока нет поддержки с бинарными модулями(нет API) -т.е. пока нет связки с mod_wsgi и mod_python.

а fcgi имхо не конкурент mod_wsgi, если речь идет о джанге.
в премениости к джанге — fcgi поддержка там не такая хорошая как с mod_wsgi.
так же fcgi имхо управление процессами происходит более громоздко для системы+презапуск сервера при изменении кода.
Вобщем, это немного разные технологии, для разных задач.
Извините, но пока не понимаю о какой поддержке вы говорите. В Джанге, разве там как-то особенно обрабатывается взаимодействие с mod_wsgi? И имеет ли это большое значение при работе проекта?

Как вы считаете, для каких задач оптимальней mod_wsgi, а для каких fcgi?
джанго заточен больше под wsgi, об этом пишут сами девелоперы.
wsgi оптимален там, где есть его полная поддержка (django,webpy,etc..)
fcgi — в остальных случаях :)

зы — да, можете называть меня Капитаном ))
Я тоже ппока не понимаю зачем такой саморазворот. Компилятор написать — одно. Компилятор из одного файла делает другой. А вот писать интерпретатор на самом языке… Ни на питоне, ни даже на Java и .NET сборщик мусора для него самого не напишешь. А раз они — на С (C++), то что за баловство? Но пусть будет, мало ли…
Ну а тот факт, что они теперь быстрее в разы, чем интерпретатор на C для Вас не является ответом на вопрос «зачем»?.. (Пока они были в 10 раз медленнее — мне тоже было не понятно зачем этот PyPy нужно вообще делать, но у них был план...)
Ну на сколько я понимаю большая часть кода этим интерпритатором транслируется в машинный(jit), поэтому не важно на чём он написан, то, что он на писан на питоне только лишь влияет на скорость компиляции… перед запуском… Очень интересно!
>> на Java [...] сборщик мусора для него самого не напишешь.

погуглите слова Jikes RVM.

это называется метациклические реализации, они имеют то достоинство, что JIT-компилятор получает возможно оптимизировать внутренности среды исполнения обычно для него недосягаемые…
aviaconstructor, может быть лучше иногда конструировать самолеты(или чем вы там занимаетесь, судя по нику)?
кроме очевидных плюсов озвученных в топике, PyPy позволяет в разы проще добавлять разные фичи в сам интерепретатор. Реализовать какой-то хак на питоне проще чем на Си — даже перекомпиляции не нужно!
UFO landed and left these words here
Хм… судя по приведенному фрагменту бинарные библиотеки не поддерживаются, следовательно, ну как минимум, общение с БД отсутствует.
UFO landed and left these words here
UFO landed and left these words here
Очень хорошо описано тут:
stackoverflow.com/questions/1410328/what-are-the-pros-and-cons-of-pyro-and-rpyc-python-libs
Если надо — могу перевести на русский.
Сам использовал RPyC для сетевого взаимодействия двух приложений, PYRO не пробовал. На тот момент я не знал о его существовании, а RPyC показался достаточно удобным. Единственным неудобством оказалась необходимость встраивать Python в клиентское приложение, т.к. оно на Delphi. Но и с этим справился.
UFO landed and left these words here
> В общем, звучит невероятно, но ребята из PyPy изобрели V8 но для Python'а.

Это совсем не V8. Там другой принцип совсем. Трассирующий JIT-компилятор, как в TraceMonkey. А в V8 — обычный. Ну а сама по себе идея JIT-компилятора совсем не нова.
> но ребята из PyPy изобрели V8 но для Python'а.
Ага, залезли в машину времени, полетели в будущее, вернулись и изобрели >_<
Ну посмотрите на даты то.
Во-первых, PyPy только сейчас обзавелся JIT-компилятором, так что никаких машин времени. V8 вышел года два назад.

Во-вторых, я не имел в виду буквально «изобрели V8», или «стырили идею у V8», или «придумали идею JIT-компиляции», я имел в виду "сделали для Python то же, что V8 сделал для Javascript".
Вот мне интересно, что в будущем может помешать разработчикам перенести эти же технологии в CPython? Разве нельзя реализовать JIT-компилятор на С?
Одна из задач проекта PyPy как раз и состоит в прототипировании и обкатки идей перед переносом их в стандарт и CPython.
UFO landed and left these words here
Вроде же предшественник PyPy — Psyco, как раз этим и занимался. Я так и не понял почему автор его бросил.

З.Ы. Если че то сильно ногами не пинайте, я не питонщик, так просто интересуюсь его жизнью :)
Псико это грязный хак. Там просто дорогостоящие операции заменялись ассемблерными вставками, в результате чего вся математика в разы быстрее работать начинала.
эт не грязный хак это оптимизация :) он не только заменял на ассемблерные вставки, он специализировал функцию под каждый возможный тип (динамически).
автор перешел на PyPy :)
бросил потому что
1) дальше его развивать уже было некуда, по сути быстрее код он генерить уже не мог
2) у PyPy гораздо больше возможности развиваться, меньше ограничений потому что это изначально исследовательский проект. и писать код на питоне (пусть и урезанном) легче чем на С.
PyPy вообще очень глубокая вещь, например одна из задач — трансляция питон-кода в другие языки (например C, вспоминаем хип-хоп пхп)
А зачем вообще сдался JIT? Почему бы всю программу не скомпилировать в машинный код заранее? А?
а еще я не понимаю нафига все вообще пишут на питоне! пусть пишут на Pure C!
Потому что на Си писать неудобно, у него очень уродливый, избыточный и местами двусмысленный синтаксис.
Это у С то двусмысленный синтаксис? В каком месте? И сколько вы программ написали на С, что бы давать хоть какие-то характеристики?
мне кажется он имел ввиду сложность разработки, слежение за памятью, более низким подходом итд =) просто высказался стандартной «дурацкой» фразой
> Это у С то двусмысленный синтаксис? В каком месте?
i++ + i++?
по логике i увеличится на один с ложится с самим собой, потом i еще на один увеличится.
p.s.
вы часто такие вещи используете в проектах?
я что-то не понимаю что двусмысленного в этом синтаксисе? синтаксис тут очень даже однозначный.
возможно вы имели ввиду семантику?
ну так тогда вся прелесть С как раз в таких вещах, именно эти двусмысленности в семантике языка позволяют компиляторам переставлять выражения и ассемблерные инструкции так чтобы процессор мог их бысрее исполнять.
Это выражение вычисляется по-разному программами собранными разными компиляторами. Если бы вы интересовались миром C/C++ то знали бы, что примерно полтора года назад в рунете была большая драма по поводу как раз таких выражений.

Двусмысленность здесь в том, что это выражение синтаксически корректно, а результат его неопределен.
вы прочитайте внимательно что я написал.
на вопрос что двусмысленного в синтаксисе с++ вы ответили примером.
пример синтаксически однозначный…
UFO landed and left these words here
Ну хорошо, просто уродливый, чего стоит

> List* l = (List * ) malloc (sizeof(List)*10);

Не многовато ли List'ов?

Также проблемы создают макросы — текст Си очень трудно распарсить/проанализировать внешней программой.

Также, надо постоянно руками писать .h файлы ко всем файлам с кодом, почему я должен делать что-то 2 раза, а? Почему я должен по 100 инклудов в начале писать? И уродливые конструкции вроде #ifndef FILE_H_INCLUDED? И компилятор потом полчаса все это компилирует. Никуда не годится.

Также невозможно работать со строками/массивами/списками, так как в Си нет объектов, а в Си++ они излишне заморочные (надо помнить про порядок вызова конструкторов, прости господи, про 4 вида конструкторов, включая к-тор копирования, все вручную освобождать, и очень много писать текста даже для каких-то простых вещей).
Вобщем, судя по маразму выше вам хочется чего-то компилируемого, но с хорошим синтаксисом? Дык берите Delphi, Eiffel, Common Lisp, FORTRAN. А вот Eiffel вообще замечательная штука, пишите на его синтаксисе, а получаете код на С.

А вообще, судя по всему, вы очень мало видели С/С++ в тех местах, где они действительно себя проявляют. Ведь вся эта мифическая сложность, которая вам так мешает, нужна для того, что бы контролировать каждый шаг программы, чего вы не сможете сделать на других языках. Не пишите на С декстопные программки, а обратите свой взор хотя бы в область embedded.

И потом не ясно, отчего вам не нравятся шарпы и явы?
Шарпы и явы тормозят и едят память непомерно.

Синтаксис хороший в Руби и Питоне, так как это относительо новые языки, и в них, видимо учтены потреьности разработчиков (но производительность плачет просто). А горбатиться над каждой буквой, в Си, как наши предки, что-то неохота.

Про Eiffel — почитаю, раньше не слышал.

Есть еще D, но там вроде автор сделал сборку мусора (фиии), и слишком «тяжелые» классы.
Вы наверно С с С++ путаете. у С как раз проблем нет по части избыточности и двусмысленности.
Да, точно. В Си++ огромное количество правил, например насчет порядка объявления и вызовов конструкторов, что ад.

Но в Си тоже есть пакости — например,

> int *a, b

или

struct lalala {
int a;
char c;
}

main()
{

}

тут ф-я main получит тип struct lalala, хотя это явно не имелось в виду

В Питоне очень много такого, что труднокомпилируемо в эффективный машинный код. Например я могу создать функцию test, затем написать test = 0, и test это уже переменная, а не функция, потом сделать class test — теперь это класс, и теперь test() вызовет уже создание объекта, а не функцию в начале. Для компилируемых языков такое поведение слишком непредсказуемо.

Но тем не менее существует shed-skin.blogspot.com, который пытается именно заниматься компиляцией хотя бы определенной части языка.
Это да, но в реальных примерах редко встречаются такие преобразования. Все-таки переменные обычно используются для хренения величин одного типа.
Хорошо, другой пример — например я могу объявить список test = [], а затем добавить в него 3(число), объект какого-нибудь класса, еще что-нибудь, например другой список, затем сделать for i in test: i.print(), что сначала попытается вызвать метод print у числа, затем у объекта, затем у списка. И если я добавлю обработчик исключений — то это правильно сработает, независимо от того у какого числа из этих объектов есть этот метов. Представьте себе какая головная боль это перевести в C++.
Ну в таких языках обычно в переменной хранится и ее тип, так что интерпретатор знает, какой метод вызвать. Никто не запрещает сделать обобщенный метод print(any), который определяет тип переменной и вызвыает нужный код. Так что при компиляции мы все равно чуть-чуть выиграем — на экономии времени на интерпретации байткода.

Но гораздо больший выигрыш будет, когда например компилятор определит что переменная хранит только int, и сразу вызовет метод print(int) для нее, не проверяя тип переменной во время работы программы.

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

В питоне — вовсе не «обычно». Самый наглядный пример — там много где может лежать и обычно лежит либо «привычный» для переменной тип, либо None. Ну, или в одну и ту же переменную может попасть объект типа int или long (совершенно другой по архитектуре). Или str и unicode.
«test» не становится ни функцией, ни классом. Разве что указывает на другой объект.
PyPy does not support the CPython C API, which means that third party libraries for python, written in C, will not work.
Это значит, что MySQLdb с ним использовать нельзя?
Да, не получиться. Но выше советуют, что можно попробовать RPyC (http://morepypy.blogspot.com/2009/11/using-cpython-extension-modules-with.html)
Как-то исследуя различные оптимизаторы кода в рамках контрольной работы по курсу «Архитектура высокопроизводительных ЭВМ» исследовал различные оптимизаторы Python'а и наткнулся на psyco(тут можно почитать подробнее psyco.sourceforge.net/introduction.html извините не могу вставлять html-код) и там же узнал, что для 64-битных платформ он не поддерживается и что мол если вам нужен psyco для x86_64 посмотрите в сторону PyPy.

Мне интерпретатор питона на питоне так же показался рекурсивным извращением, но немного погоняв псайко я подумал, что видимо в рамках реализации этого интерпретатора разработчики пытаются обойти ограничения прямой оптимизации генерируемого байт-кода. Ещё поудмал, что может у них что-то и получится. Видимо так и вышло :)

Для реализации контрольной работы выбрал CorePy. О нём уже писали вот здесь habrahabr.ru/blogs/python/45726/. По личному опыту скажу, что оно действительно работает и на самом деле снова привносит в программирование на ассемблере фан.
Прямо наплыв питона, что вы в нем нашли? аж завидно стало, что он так постоянно развивается.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Все! :)

Классы, очень широкую библиотеку расширений (PyPi, easy_install), исключения (первое время после PHP напрягает что любая ошибочка вызывает остановку, если не предусмотрена обработка, потом PHP начинает напрягать, что он молча пропускает ошибки), генераторы(великая вещь!), стандартную библиотеку, конечно вдоль и поперек надо изучить — полезного очень много. Такие вещи как: if 1 < x < 10, [(i+1) for i in range(10) if i%2==0], a,b=b,a, и т.п.

Еще здесь — stackoverflow.com/questions/101268/hidden-features-of-python

И что важно — очень чистый синтаксис — все программы Python очень аккуратно форматированы (иначе просто не запустятся).
UFO landed and left these words here
Отсутствие public и private, конечно может быть решение с которым я не очень согласен, но привык — таков питон, в нем все можно динамически переназначать.

Кроме того, методы можно называть __method_name — тогда они не будут видны снаружи класса.

Я не гоню на PHP — это очень успешный язык. Я говорю о том, что многие решения в Python куда лучше сделаны чем в PHP. Но конечно пространства имен в PHP — это решение, которое меня будет доооооолго еще озадачивать (за использование "\" на PHP гнать надо).
если бы сейчас везде python и php поменялись в одночасье мир стал бы счастливее, следовательно…
Новость хорошая, а подача очень слабая. Попробуйте перед восторженными криками почитать что ли внимательно. По пунктам всей ветке:
1. пишется он на RPython, на самостоятельное чтение;
2. транслятор с python на C++ есть — shed-skin.blogspot.com/;
3. есть драйвера к базам данных, написанные на чистом python.
Короче жгете.
Хорошая новость и не всё равно ли, как они добились ускорения, если пользователям от этого только лучше? Надеюсь, что разговоры о медлительности Питона пойдут на убыл.
Прикольно, конечно, но чтобы писать на джанго помимо ждрайверов к БД почти всегда нужен как минимм PIL, а чтобы писать для десктопа — PyQt. Ни того, ни другого нету… В итоге эксперимент, конечно, интересный, но всего лишь эксперимент.
>please consider it a beta version to try things out.

когда выйдет полноценная версия, тогда и можно подумать об использовании.
Думать об использовании PyPy вообще не стоит. Это научный исследовательский проект, обгрантованный ЕС и другими. Использовать можно будет выхлоп, а не непосредственный результат.
А можно поподробнее, в чем суть JIT-компилятора? Обычный питон ведь тоже компилирует исходники в байт-код.
UFO landed and left these words here
если ваш тест корректен, но да, увеличение скорости в 9 раз я зафиксировал
Для руби тоже существует подобный проект — Rubinius. Отличия в том что он поддерживает стандартные си расширения Ruby и видимо младше PyPy — текущая версия 1.0.0rc3. А вот perl на perl или php на php я что-то не припомню :)
>Для руби тоже существует подобный проект — Rubinius

разве? Я думал Rubinius — это просто реализация виртуальной машины Руби под LLVM?
Rubinius это прежде всего руби на руби. Некоторые части написаны на C++ а llvm используется для ускорения выполнения кода.
>Rubinius is an implementation of the Ruby programming language.

>The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby.

Тут как я понял тоже самое
Не очень только понятно зачем было пинать unladen swallow, коли он вообще из другой плоскости.
Unladen swallow — an optimization branch of CPython, intended to be fully compatible and significantly faster.
ну, вы слишком строги.

к тому же PyPy-евцы до сих пор интересуются возможностью когда-нибудь опять попробовать сесть на LLVM, а один из них вроде статический бэкенд пописывал для LLVM в ранние годы.
Я не строг =) Я защищаю несправедливо обиженного гуглозмея. :)
он не оценит ;)

P.S. а потом, после того как они решили забить на 2.6.х — я вообще не уделяю им больше столько внимания и надежд…
что интересно они сели на свой JIT — никаких связей с LLVM, JVM, .NET
(как я помню, с LLVM они пробовали, но любовь не сложилась.)

Было бы прикольно, если бы они выделили свой JIT в самостоятельный проект…
они сейчас активно занимаются всем тем что вы сказали. пишут бэкэнды для LLVM, JVM и для .NET

на самом деле сейчас PyPy уже не так сильно привязан к питону. она зарождался как питон на питоне, чтоб быть более переносимим и легко можно было прототипировать новые фишки. но сейчас на нем можно писать что угодно. это по сути есть фреймворк, где вы на спецязыке RPython (по сути питон без динамичных плюшечек) пишите интерпретатор, аннотируете его местами и фреймворк генерит вам интерпретатор с джитом. в теории можно писать не только для питона. просто наверно никто этим пока не занимался.
Only those users with full accounts are able to leave comments. Log in, please.