LINUX.ORG.RU

Релиз PyPy 7.0

 ,


1

1

Состоялся релиз PyPy 7.0 — свободной реализации Python для Linux (x86, x86_64, PPC64, s390x, ARMv6 или ARMv7 с VFPv3), macOS (x86_64), OpenBSD, FreeBSD и Windows (x86). Особенностью PyPy является JIT-компиляция, на лету транслирующая некоторые элементы в машинный код, что позволяет очень сильно ускорить приложение.

Что нового:

  • Представлен первый альфа-выпуск PyPy3.6, предоставляющий поддержку Python 3.6.
  • Добавлена возможность подключения обработчиков к сборщику мусора (GC hooks), позволяющих на низком уровне управлять поведением сборщика мусора.
  • Обновлены модули CFFI 1.12 и cppyy 1.4 с реализацией интерфейса для вызова функций, написанных на языках Си и C++.
  • В ветках PyPy 3.5 и PyPy 3.6 появилась поддержка cppyy, который раньше был доступен только в PyPy 2.7.
  • Реализованы специфичные для Python 3.6 функции и объекты Py_ReprEnter, Py_ReprLeave(), PyMarshal_ReadObjectFromString, PyMarshal_WriteObjectToString, PyObject_DelItemString, PyMapping_DelItem, PyMapping_DelItemString, PyEval_GetFrame, PyOS_InputHook, PyErr_FormatFromCause, __set_name__, __init_subclass__.
  • В основную ветку PyPy переведена разработка отладчика revdb с поддержкой отладки с возвратом к более ранним состояниям (reverse debugging).
  • Добавлена поддержка платформы GNU Hurd.
  • Улучшена работа в окружении FreeBSD.
  • Код для перевода внутреннего представления строк на UTF-8 в релиз не вошёл.

>>> Подробности

Deleted

Проверено: Shaman007 ()
Последнее исправление: Virtuos86 (всего исправлений: 2)

Ответ на: комментарий от instant

Это неловкое чувство

когда нужно делать скоростной код и ты пишешь на Питоне

Зависит от задачи, конечно. Но задач, где питону не хватает производительности, очень мало.

Обычно всё наоборот: надо не написать быстрое решение, а быстро написать решение. И вот тут питон хорош.

А оптимизировать можно и позже — у питона много путей оптимизации. От jit-ов вроде pypy, до компиляции в нативные бинарники cython-ом.

pynonymous
()
Ответ на: комментарий от Virtuos86

А ведь первого раза должно было хватить, чтобы понять, что памяти не хватает.

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

imul ★★★★★
()
Ответ на: комментарий от pawnhearts

Отступы починили? Многострочные лямбды есть?

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

pynonymous
()
Ответ на: комментарий от oldstable

Проблема руби, что он от Питона отличается слабо, но при этом имеет много более слабую экосистему.

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

bread
()
Ответ на: комментарий от pynonymous

Отступы и не ломались. А многострочные лямбды, в принципе, есть...

Эта песня хороша, начинай сначала.

bread
()
Ответ на: комментарий от pynonymous

Но задач, где питону не хватает производительности, очень мало.

Только благодаря сишным модулям. Без них любая элементарная задача стала бы проблемой. В то время как с нормальным языком можно просто писать либы на этом языке, а не скакать с бубном вокруг сишного апи на любой чих. Проблема питоноадептов: вы все время забываете, что у вас недоязычок-клей, а не ЯП общего назначения. Очень легко впасть в это заблуждение, потому что питон сильно похож на такой ЯП, но не является им. Вот с перлом, луа или жс все хорошо в этом плане, а рубисты как-то держат себя в руках (их недоязычок тоже похож на настоящий).

bread
()
Ответ на: комментарий от bread

не ЯП общего назначения

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

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

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

DonkeyHot ★★★★★
()

Код для перевода внутреннего представления строк на UTF-8 в релиз не вошёл

Это ученый изнасиловал журналиста или в чем идея менять внутреннее представление строк на utf8?

anonymous
()

Мне кажется более целесообразным писать на Python только тот код, который не требует высокой производительности. Куски кода в котором нужна производительность нужно писать на си, собирать в so, и подключать к Python через cffi

Archer73
()
Ответ на: комментарий от bread

Отступы и не ломались. А многострочные лямбды, в принципе, есть...

Эта песня хороша, начинай сначала.

Не тот кусок цитируешь. Правильный кусок:

но я не знаю случаев кода, который с многострочной лямбдой был бы лучше

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

Если не знаешь питона — предложи на любом другом языке, я переведу.

pynonymous
()

Интересно, почему офтопик только 32? Где 64?

Vinni_Pooh ★★★★★
()
Ответ на: комментарий от Archer73

Куски кода в котором нужна производительность нужно писать на си

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

Но в случае питона есть три особенности.

Во-первых, очень редко нужна «максимально возможная производительность». В большинстве задач нужна «достаточная производительность». Если питонокод выдаёт результат за секунду, и этого достаточно, то глупо тратить время и оптимизировать его до четверти секунды. Оптимизируют — когда это нужно.

Во-вторых, если не хватает совсем немного скорости, то, чтобы не переписывать, можно запустить этот же код jit-ом вроде pypy. Вот в этом и хорош PyPy — прирост скорости без траты времени на оптимизацию.

В-третьих, если и этого не хватило, то не надо переписывать на си, можно сгенерировать сишный код, если расставить типы и пройтись cython-ом. Он сам конвертирует данные из питоновых типов в сишные и обратно.

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

pynonymous
()
Ответ на: комментарий от instant

Это неловкое чувство

когда нужно делать скоростной код и ты пишешь на Питоне

Это чувство характерно для всех интерпретаторов

ism ★★★
()
Ответ на: комментарий от pawnhearts

Отступы починили? Многострочные лямбды есть?

Вы хоть бы реальные проблемы упоминали, а не какую-то вкусовщину.

oldstable
()
Ответ на: комментарий от ArkaDOSik

То, что PyPy интерпретирует питон - побочный эффект. Цель pypy - удобный jit для произвольных языков. Но писать jit на Сях - упороться: долго и больно. Поэтому его написали на промежуточном языке, который оказался похож на питон. Поэтому и прикрутили питона.

Вообще pypy он self-hosted то есть написан сам на себе. Это примерно также как gcc написан на gcc (они сами свои расширения используют и, например, msvc'ой не собираются) но может принять пару других языков потом.

anonymous
()
Ответ на: комментарий от buddhist

Что вообще происходит?

новаторский подход к этим вашим цифрам, кажется

rust_afari
()
Ответ на: комментарий от bread

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

wisedraco ★★
()
Ответ на: комментарий от pynonymous

И это справедливо для любого языка, не только для питона

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

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

да ты же поехавший

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

bread
()
Ответ на: комментарий от wisedraco

нужны только два языка - асм для скррости и эффективности, и питон для быстроты и простоты

Оба мимо. Асм не нужен если ты не компилятор, питон нифига не простой, а наоборот переусложнен.

bread
()
Ответ на: комментарий от bread

Но асм же позволяет наиболее маленький и быстрый код создавать?

Что есть проще, но сравнимео по возможностям с питоном?

wisedraco ★★
()
Ответ на: комментарий от wisedraco

Но асм же позволяет наиболее маленький и быстрый код создавать?

Или маленький, или быстрый. И тот и другой создаётся оптимизатором, смотря какую опцию указать.

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

anonymous
()
Ответ на: комментарий от wisedraco

Что есть проще, но сравнимео по возможностям с питоном?

Жабаскрипт.

bread
()
Ответ на: комментарий от wisedraco

Он ыкзе из программы умеет делать?

JIT-интерпретатор же. Ыкзе делаются компиляторами. На худой конец есть AOT.

anonymous
()
Ответ на: комментарий от wisedraco

А cython чё такое по-твоему? Другое дело что они все libpython линкуют и автоматически збс не сделать, но это и не нужно. Зачастую достаточно пару букв написать чтобы получить ускорение в 10000+ раз.

anonymous
()
Ответ на: комментарий от anonymous

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

Ну, да, нуитка ещё. И всё...

wisedraco ★★
()
Ответ на: не ЯП общего назначения от DonkeyHot

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

be_nt_all ★★
()
Ответ на: комментарий от wisedraco

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

be_nt_all ★★
()
Ответ на: комментарий от wisedraco

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

be_nt_all ★★
()
Последнее исправление: be_nt_all (всего исправлений: 1)
Ответ на: комментарий от be_nt_all

Таак, а можно пойти от начала? В юности я читал что язык может преобразовыватся в машинный код либо интерпретатором, либо компилятором

Что мешает любой язык и так и этак транслировать?

wisedraco ★★
()
Ответ на: комментарий от wisedraco

А я в юности читал древнюю (уже тогда далеко не новую, хотя потом было четыре пересмотренных переиздания) книжку Теренса Пратта «Языки программирования: разработка и реализация». Там языки сравниваются по времени связывания чего-то с чем-то. В языках со статической типизацией переменная связывается с типом во время компиляции, с динамической — во время исполнения. Более позднее время связывания влечёт за собой усложнение рантайма (и, следовательно, результат трансляции будет больше похож на интерпретатор, напомню, что чистый интерпретатор, это разве что какой-то bash, все языки программирования используют трансляцию исходного текста в некий промежуточный код). А ещё есть время связывания во время определения языка. Как знаки операций в C (но не C++). Такое время связывание позволяет писать быстрые и простые компиляторы (к С это относится, см. к примеру tcc, C++, очевидно, не из таких). Это если вкратце.

зы. В Питоне динамики/позднего связывания хватает.

be_nt_all ★★
()
Последнее исправление: be_nt_all (всего исправлений: 2)
Ответ на: комментарий от be_nt_all

В моей юности были бк0010, двк3 и тотальный дефицит книг по этим темам в магазинах.

Насчёт связывания - энивей невижу никаких причин.

wisedraco ★★
()
Ответ на: комментарий от wisedraco

А, в моей тоже. Хотя ещё программируемый микрокалькулятор и ZX-клоны (а ещё я видел работающие БЭСМ-6 и Наири). Книжку купил в букинистическом отделе магазина тех.книга в центре моего города (точнее областного центра, в пригороде которого живу). Хотя TurboPascal учил по изданной в Польше на польском языке книге, купленной в «Глобусе».

Второе предложение слегка не распарсил? Причин для чего?

be_nt_all ★★
()
Последнее исправление: be_nt_all (всего исправлений: 1)
Ответ на: комментарий от wisedraco

Вот когда (если?) в институт поступишь на соответствующую специальность, расскажут. Ещё и свой компилятор придется написать.

anonymous
()
Ответ на: комментарий от be_nt_all

Причин препятствующих предварительной трансляции в машинный код.

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

wisedraco ★★
()
Ответ на: комментарий от wisedraco

Ну я в 1990 видел у человека собранный им лично (в 1989) клон спектрума. Массово да, 1992, брат мой младший на таком в игры играл.

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

И да, на всякий случай, машкод i8086 уже был заметно тяжелее человекочитаем, чем система команд PDP-11 (как в БК-0010, ДВК 2-3, Электроника-60 и УКНЦ). x86-64 с кучей слоёв legacy и подавно тяжёл. Это к тому, что на тех машинах бэкенд компиляторов было определённо легче писать.

be_nt_all ★★
()
Последнее исправление: be_nt_all (всего исправлений: 1)
Ответ на: комментарий от Archer73

Мне кажется более целесообразным писать... на си, собирать в so, и подключать к Python через cffi

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

Наиболее оптимальный вариант старые добрые нативные экстеншины, которые на сишной стороне парсят питонские объекты на вход и создают их для передачи на сторону интерпретатора на выходе.

Linfan ★★★★★
()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от wisedraco

асм для скррости и эффективности, и питон для быстроты и простоты

Ты забыл про переносимость

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

instant
()
Ответ на: комментарий от WitcherGeralt

Поробуй назвать сотя бы пять широко распространённых языков общего назначения код на которых не состоятелен без дописывания расширений на сях. Ну пусть будет четыре, руби не называй.

java и производные, javascript, php, perl, tcl, lisp, bash... Смотря какой язык считать языком «общего назначения», и что считать «не состоятельным». Сишные экстеншны и библиотеки почти во всех языках используются.

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

pynonymous
()
Ответ на: комментарий от pynonymous

4.2, 4.2, мб, 4.2, юзают полтора инвалида, ололо, не язык общего назначения.

которые не используют модули или библиотеки на сях?

Я даже отвечать на эту тупость не буду.

WitcherGeralt ★★
()

yCTPOy_Destroy

это чья реинкарнация интересно скор фармит

Harald ★★★★★
()
Ответ на: комментарий от WitcherGeralt

4.2, 4.2, мб, 4.2, юзают полтора инвалида, ололо, не язык общего назначения.

Хм... Прямо 4.2? И на чём же там пишут высокопроизводительный код? Например, в каком из этих языков есть быстрая арифметика произвольной точности без сишных расширений?

pynonymous
()
Ответ на: комментарий от be_nt_all

языки заточенные на написание эффективного кода

Буквальное определение DSLя же?

Однако то, что си и родственники, на самом деле, заточены на написание эффективного кода - весьма спорно. Во первых, эффективности бывают разные, и часто конфликтующие — на поверхности сознания, в произвольном порядке: 1. размер рантайма, 2. время выполнения, 3. потребляемая память, 4. скорость написания, 5. стоимость поддержки

Си — можно считать, заточен на первое — просто потому, что почти не отсебятит. Но это нужно только редким встроителям. И он точно ничего не делает для 2  — авторам компилеров приходится изрядно изобретательствовать, чтобы сохранить смысл кода при оптимизации. 3 - полностью на совести автора, «Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out!»

C++ продажа 1-2 за немножко 4, числится в списке «быстрых» только потому, что осторожные программисты могут найти выгодный балланс,

И т.д. Суть сего в том, что «не мешать добиться Ф» и «быть заточенным для Ф» - разные вещи.

их принято считать именно что языками общего назначения

Формально, «язык общего назначания» — язык, одинаково плохо подходящий для любых(широкого круга, как минимум) задач. Язык, в котором нет специфичных вкусностей. Наличие/отсутствие способов добиться какой-то из эффективностей доменной спецификой считать не получается — эффективность везде приятна.

«а мужики-то не знаютзабыли»

что разница возможностей «получить приемлемо работающий за приемлемое время код» и «получить за приемлемое время приемлемо работающий код» — никак не относится к понятию «общего назначения».

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.