I'm very impressed with pypy. The test suite for my python-based scheme compiler runs in about 1m10s using cpython, and in about 17 seconds with pypy.

#python #pypy

There's been a noticeable increase in PyPy development activity in the last couple of months. Makes me very happy.

A lot of that comes from new energy from @stanfromireland, the newest PyPY core developer. But it also seems @mattip and @cfbolz are more active too, and users seem to be filing more issues and even proposing more PRs.

I can't explain this uptick in activity, any theories?

#Python #PyPy

#gentoo plans to switch from Python 3.13 to πthon 3.14 on 2026-06-01. https://www.gentoo.org/support/news-items/2026-04-16-python3-14.html

"Other πthon implementations
============================
At the same time, we are also going to remove the target support for πthon 3.11 (πthon3_11) and ππ 3.11 (ππ3_11). Since there are
no plans to release a πthon 3.12-compatible ππ version yet, Gentoo will be removing ππ support for the time being."
:-(

#PyPy

PSA: The annual #Gentoo #Python switch planned for 2026-06-01. CPython 3.14 becomes the default, 3.11 and #PyPy 3.11 go out. The latter fills me with sadness but keeping it is unrealistic now that projects are aggressively pushing for 3.12+.

Of course, we'll continue shipping the interpreters, so you can use venvs if you like. However, that's going to become harder to use since many projects either don't ship PyPy wheels or don't work on PyPy at all without patching.

We will revisit PyPy support if a version compatible with Python 3.12 appears in reasonable time.

https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u

I was already having misgivings about #CPython when I saw a required #Rust dependency coming up (although I know many here have no issues with this), but now that there have been #LLM commits to the project, I'd like to look at alternatives. It seems great that #Pypy exists, although I worry that it will end up replicating undesirable behavior from CPython in the future.

I had been learning C++ with the goal of writing extensions using CPython. As it happens, I already have a physical copy of a book on #Lua and many applications are written in C++ with Lua scripting on top, so I'm going to swap out Python for Lua in an upcoming project. I'm excited to be able to experiment with #LuaLaTeX or writing scripts for #GeanyIDE. The language shows up in way more places than I realized.

#Python #cpp #CPlusPlus #programming #Scripting #ScriptingLanguage #TexLatex

https://blog.gslin.org/archives/2026/03/19/12941/%e5%be%88%e5%a4%9a-python-%e5%8a%a0%e9%80%9f%e7%9a%84%e6%96%b9%e6%b3%95/

很多 Python 加速的方法

#c #code #codon #compiler #cpython #cython #graalpy #jax #mojo #mypyc #native #numba #numpy #performance #pyo3 #pypy #python #rust #speed #taichi

With CPython now actively merging "AI" slop in the form of co-authored commits from Anthropic Claude… I'm leery about starting new projects atop the reference #Python implementation.

My projects remain slop-free at this point in time, and it is my intention that they stay that way. I can't afford the legal risk that comes with them: a machine cannot represent itself in court, therefore a machine cannot be held accountable for infractions of copyright law. This means the buck stops with the humans.

Cursory glance at Pypy, it is compatible with Python 3.11 and, on the surface, does not show any co-authored commits. I've used it in the past and found it to be mostly compatible.

Is it good enough for a fork? Did I miss something?

https://github.com/pypy/pypy

#Pypy #Pypy3 #NoAI