LINUX.ORG.RU

Сдвоенный выпуск PyPy2.7 и PyPy3.5 v6.0

 ,


1

3

Команда разработчиков PyPy выпустила PyPy2.7 v6.0 (интерпретатор, поддерживающий синтаксис Python 2.7) и PyPy3.5 v6.0 (интерпретатор, поддерживающий синтаксис Python 3.5). Оба выпуска во многом основаны на единой кодовой базе, что и позволило подготовить их совместный выход.

PyPy — совместимый интерпретатор Python, во многом годящийся на бесшовную замену CPython 2.7 и CPython 3.5. PyPy быстр (сравнение производительности PyPy и CPython 2.7.x), благодаря встроенному трассирующему JIT-компилятору.

Этот выпуск продолжает линию, намеченную предыдущим выпуском 5.10 в декабре 2017 года.

  • cpyext, слой совместимости для C-API, теперь как намного быстрее (запись в блоге), так и более близок к завершенности. Сделано много других улучшений в плане скорости и совместимости с CPython. Поскольку изменения влияют на подключаемые заголовочные файлы Python, все Си-расширения должны быть перекомпилированы заново для этой версии.
  • GC теперь имеет хуки, для получения большей информации о его производительности.
  • TkAgg, бэкенд Matplotlib по умолчанию, теперь работает с PyPy, также как и pygame, и pygobject.
  • Обновлены библиотека cffi до версии 1.11.5 и бэкенд cppyy до версии 0.6.0.

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

  • Выпуск PyPy3.5 для Windows по-прежнему считается находящимся в статусе «beta». Есть открытые замечания, связанные с обработкой Юникода, особенно вокруг системных вызовов и Си-расширений.
  • utf8-ветка, которая изменяет внутреннее представление Юникода на UTF-8, не вошла в выпуск.

Выпуск v6.0 можно загрузить отсюда: http://pypy.org/download.html

PyPy поддерживает:

  • x86-машины с большинством основных ОС (Linux 32/64 битные сборки, Mac OS X 64 …, Windows 32 …, OpenBSD, FreeBSD);
  • новое ARM-«железо» (ARMv6 или ARMv7, с VFPv3) под управлением Linux;
  • big- и little-endian варианты PPC64 под управлением Linux;
  • s390x под управлением Linux.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 7)
Ответ на: комментарий от Linfan

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

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

Ты читать пробовал? Благодаря быдлокодерам вроде тебя мы сейчас имеем запросы к БД, которые могут исполнятся бесконечное время, html-страницы, которые могут грузиться бесконечное время и даже файлы PDF, которые могут зависать при открытии.
Байт-код не имеет никакого отношения к тьюринг-полноте самого языка. Программа на одном и том же языке может исполнятся построчно (привет, R!), может компилироваться в машинный код или в помесь ежа с ужом, называемую байт-кодом.

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

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

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

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

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

ты - теоретик который где-то что-то слышал, как впрочем и афторы питона

Какой уровень программистов в треде, с ума сойти.

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

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

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

Мальчик, ты заблудился? Где твои родители? Сколько тебе лет?

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

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

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

Какой уровень программистов в треде, с ума сойти.

нудык! синьоры с 3х летним опытом это вам не какой-нить Ван Россум или Торвальдс. Это цвет лоровской нации :)

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

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

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

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

Ну давай, соптимизируй и выполни за минимальное время следующий код:

10 GOTO 10

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

Какой уровень программистов в треде, с ума сойти.

Это уровень ровно одного персонажа. Который то ли троллит тупизной, то ли реально тупой.

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

Одно только протаскивание this явным аргументом чего стоит

Си++-утятам трудно, но идея правильная.

Надо же, хоть кто-то по существу ответил. Почему она правильная? Разжуйте плиз C++-утёнку. :)

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

Это уровень ровно одного персонажа. Который то ли троллит тупизной, то ли реально тупой.

Троллит 100%. Очень свежий и прикольный взгляд на тьюринг-полноту. :) Будь я преподом, обязательно взял бы на вооружение - студентов-недоучек заваливать.

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

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

та шо вы говорите )) Вот прям бинарь стартануть и поедет? Или все-таки через прослойку эмулятора? А кто мешает благородным донам прикрутить эмулятор py2 к py3? И что это поменяет концептуально на практике?

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

через транслятор, а не через прослойку эмулятора. это как раз то, что питон 3 не может (не тьюринг-полный). да, стартануть бинарь и поедет.

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

Питон давно пора закопать. Почему с этим убогим язычком все носятся? Он же хуже php.

так хорошо начал. я уж подумал, вот, разумный человек...

Всем по go, посоны.

а потом как ляпнет.

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

это как раз то, что питон 3 не может

Не может принципиально или просто это нахрен никому не уперлось?

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

Питон давно пора закопать. Почему с этим убогим язычком все носятся?
Всем по go, посоны.

Называть питон убогим и предлагать ему на замену ещё более убогий го — это сильно.

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

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

Потому что метод - это функция, и явное лучше неявного.

Как по мне, это чистое теоретизирование. С практической точки зрения, разница синтаксисов o.f() и f(o) даёт полезную информацию об инкапсуляции при чтении кода: метод - значит объявлен в теле класса, имеет доступ к приватным членам, а в случае библиотечного класса это может означать также невозможность этот метод переопределить... Ах, да, это ж питон: ни инкапсуляции, ни приватных членов, ни final keyword. :)

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

Потому что метод - это функция, и явное лучше неявного.

Как по мне, это чистое теоретизирование

Это потому, что с Python ты знаком в лучшем случае никак.

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

Согласен: разговоры об инкапсуляции применительно к питону - это теоретизирование. :)

мдя... и эту критику наводит пхпшник )))

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

Это потому, что с Python ты знаком в лучшем случае никак.

Я пока что не увидел конкретных аргументов, чем на практике вызов f(o) удобнее чем o.f(). А твой ответ - это ещё не переход на личности, но уже близко; по крайней мере отказ таковые аргументы предоставить позволяет предполагать, что их нет.

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

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

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

мдя... и эту критику наводит пхпшник )))

Не желая никаким образом хватить php, имею тем не менее сообщить, что в нём есть и public/protected/private, и final. :)

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

ну судя по возне с питон 2, не может принципиально.

мсье, вы сильно удивитесь, но несовместимость байтккода к «возне с py2» не имеет никакого практического отношения. Скорее можно выкатить претензии к Эппл, которые упорно торчат на 2й версии и не хотят съезжать на 3ю, чем к хрен пойми кому нужной исполняемости байткода 2й версии на py3.

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

Я пока что не увидел конкретных аргументов, чем на практике вызов f(o) удобнее чем o.f()

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

А твой ответ - это ещё не переход на личности, но уже близко

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

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

Не желая никаким образом хватить php, имею тем не менее сообщить, что в нём есть и public/protected/private, и final.

Это концептуально что-то поменяло в развитии сайтов, к которым лично вы приложились? Или весь этот треш, который притащили в пхп из полноценных языков, просто греет душу «у нас усе как у взрослых дядей»? ;)

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

Тебе ответили, почему явный self - хорошая идея.

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

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

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

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

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

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

Это концептуально что-то поменяло в развитии сайтов, к которым лично вы приложились? Или весь этот треш, который притащили в пхп из полноценных языков, просто греет душу «у нас усе как у взрослых дядей»? ;)

А вот это хороший вопрос. :) В случае php - нет. Но я и написал - «не желая никаким образом хвалить php». Единственный язык из мне известных, где всю эту инкапсуляцию было действительно удобно и быстро писать - scala. Очень компактный и чертовски приятный синтаксис. Ну и статическая типизация ейная выносит со свистом всех остальных вместе взятых. Во всех остальных языках - проще забить, чем всё это выписывать. Хотя на работе выписывал, конечно, но по ощущениям динамическая типизация индуцирует на порядки больше багов, чем плохая инкапсуляция.

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

Тебе ответили, почему явный self - хорошая идея.

Нет, не ответили

Просто ты не понял ответа.

Программирование - практическая дисциплина. В которой все теории о том, что хорошо, а что плохо, не только проверяются практикой

Глубоко копаешь.

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

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

А причина одна - Тьюринг-неполнота.

tailgunner ★★★★★
()

«Сдвоенный выпуск пи-пи»

Спасибо, улыбнулся.

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

и к гуглу, они тоже ничего не портируют на питон 3. и ещё много к кому, много известных имён наберётся

за всю IT не мого сказать, но на ниве клаудов все известные имена, включая гугл, бодро переехали на py3.

сервисы которые написаны на питоне 2 и которые уже стоят в продакшене никто никогда не будет переписывать на питоне 3

дык! И сцайты, на php4 писанные, тоже не будут переписываться - нет смысла. Работает, значит дешевле поддерживать до самой смерти сервисов по бизнес причинам.

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

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

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

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

Но это верно лишь с учётом того, что обычно я пишу в anemic-архитектуре: данные отдельно, логика отдельно. Когда гоняешь туда-сюда raw data, вопрос о private/publiс вообще на стоит. Самое то для веба-энтерпрайза-прочего формоклёпства. Но наверное есть области, где data hiding существенно важнее.

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

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

Вот и славненько. Теперь иди в палату.

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

включая гугл, бодро переехали на py3.

да? а склонировать исходники хрома и посмотреть, не? погуглить grumpy, не? или рабинович по телефону напел?

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

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

И ессно, scala как Неуловимый Джо - даже в двадцатку популярных ЯП не входит :)

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

Это по ощущениям. А по статистике ЯП с динамикой сокращает объем кода до 5 раз. То ли 2 года писать проект, то ли 10 лет его пилить - какбэ оно того стоит, чтобы перестроить сознание на динамику и не мыслить шаблонами статики.

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

1. Объём кода и динамика - вещи строго говоря вообще ортогональные. Два ключевых момента компактности кода - вывод типов и метапрограммирование. И то, и другое вполне реализуемо на статике - и скала этому доказательство. В пять-не пять, но по оценкам Одерски в три раза скала-код компактнее жавовского.

2. Объём кода и время разработки - вещи строго говоря не связанные жёстко. Потому что статика ловит обширный класс ошибок, включающий опечатки и т.п. Математически гарантированно ловит. Чтобы достигнуть сопоставимой надёжности быстро написанного и компактного кода на динамике, приходится писать на порядки больше тестов. Ну или забить, нехай в рантайме вылетает.

3. И самое главное: в силу п.2, на динамике дьявольски трудно рефакторить. Никакой помощи от компилятора. На статике я переименовал метод - и если где-то (например, вообще в другом проекте) IDE его не переименовала, компилятор гарантированно выловит ошибку. И чем круче статика, тем быстрее и размашистее (гораздо более крупными шагами) я могу рефакторить, не боясь ничего поломать. А питонщики и прочие пхпшники с js-никами получат ошибку в рантайме. А для больших долгоиграющих проектов скорость и надёжность рефакторингов - критична.

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