#pypy — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #pypy, aggregated by home.social.
-
#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."
:-( -
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
-
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?
-
Python Standard Library для спортивного программирования
Стандартная библиотека Python содержит множество инструментов, которые значительно упрощают решение задач спортивного программирования, но многие из них остаются незамеченными начинающими участниками. В статье собран краткий конспект по наиболее полезным модулям и функциям стандартной библиотеки с небольшими примерами.
https://habr.com/ru/articles/1010290/
#спортивное_программирование #питон #python #pypy #standard_library #стандартная_библиотека #стандартная_библиотека_python #icpc #codeforces #topcoder
-
Even a decade back, when #PyPy was showing promising performance benefits of 4x speedup or even more, it was of little benefit to an increasingly compiled scientific stack. PyPy was only useful in a Pure Python environment, so I am not surprised with its removal from #NumPy
https://github.com/numpy/numpy/issues/30416
However I am genuinely surprised to hear that PyPy as a project is "no longer under active development, and has not released a Python3.12 version." I think the emphasis is on the latter, that it takes time for PyPy to catch up to Python 3.12 and due to NEP29 they should only support Python 3.12+.
https://numpy.org/neps/nep-0029-deprecation_policy.html
I haven't seen an official announcement of PyPy being discontinued and would refuse to believe that until I see one.
-
🚨 Oh no, #PyPy might be unmaintained! Quick, someone alert the world before it collapses into chaos! 😂 Meanwhile, #GitHub wants you to think #AI will save us all, but just needs your firstborn in exchange for a few lines of "better" code. 🤖
https://github.com/astral-sh/uv/pull/17643 #Unmaintained #Chaos #TechNews #HackerNews #ngated -
https://github.com/numpy/numpy/issues/30416#issue-3718116466
This is the saddest news I’ve heard recently: #PyPy is no longer under active development.
It is so bad to know that [they originally did not intend to go beyond 3.10](https://github.com/orgs/pypy/discussions/5145#discussioncomment-13121917).
-
In the #Python programming language, the new #REPL from Python 3.13 (2024) has added colorization in the #interpreter in #interactive Python, similar to the interface seen in later versions of #PyPy. Python 3.14 (2025) and Python 3.15 (2026) continue along with the improved REPL with the colorization of the Python #syntax itself.
-
In the #Python programming language, the new #REPL from Python 3.13 (2024) has added colorization in the #interpreter in #interactive Python, similar to the interface seen in later versions of #PyPy. Python 3.14 (2025) and Python 3.15 (2026) continue along with the improved REPL with the colorization of the Python #syntax itself.
-
In the #Python programming language, the new #REPL from Python 3.13 (2024) has added colorization in the #interpreter in #interactive Python, similar to the interface seen in later versions of #PyPy. Python 3.14 (2025) and Python 3.15 (2026) continue along with the improved REPL with the colorization of the Python #syntax itself.
-
In the #Python programming language, the new #REPL from Python 3.13 (2024) has added colorization in the #interpreter in #interactive Python, similar to the interface seen in later versions of #PyPy. Python 3.14 (2025) and Python 3.15 (2026) continue along with the improved REPL with the colorization of the Python #syntax itself.
-
just used #PyPy to accelerate an Amaranth simulation from 35s to 17s (no code changes)
it's pretty good
-
#Sphinx joined the list of packages dropping #Python 3.11 (and therefore #PyPy) support. Of course, we could just go through the effort of dropping it from respective packages in #Gentoo, given it's not technically that common… but honestly, at this point I have zero motivation to put the extra effort for this, just to learn that next month some core package starts requiring Python 3.12.
So, would anyone really mind if I removed Python 3.11 and PyPy support completely from Gentoo packages?
-
niklas-heer/speed-comparison: A repo which compares the speed of different programming languages.
https://github.com/niklas-heer/speed-comparisonThis projects tries to compare the speed of different #programming languages. It uses an implementation of the Leibniz formula for π to do the comparison.
Notably:
- #Julia is the only dynamically-typed languages amoung the top tier, only ~28ms slower from #Cpp (#Clang).
- #Rust got a huge boost with nightly compiler (it is said that hand-written SIMD is used?)
- #Go tops in 3rd tier (very crowded 0.8s~1s)
- #PyPy and #Haskell (#GHC) are very closed (~1s), preceding #Racket, beating #Python (#NumPy) by a lot (~1.2s)
- The slowest is #CPython (~86s) -
W przypadku #PyPy, przyczyną jest zawsze jakiś wyciek zasobów…
-
For #PyPy, it's always a resource leak…
-
Jakiś czas temu, zainspirowany #Fedorą, wyodrębniłem paczki .whl z Pythonowego ensurepip w #Gentoo (właśnie sprawdziłem — "jakiś czas" to 3 lata). Umożliwiło to nam aktualizowanie ich razem z paczkami pip i setuptools, dzięki czemu nowe środowiska wirtualne otrzymują najnowszą dostępną wersję, a nie tę, którą włączono w dane wydanie CPythona.
Myślałem wówczas, by budować je z naszych systemowych paczek, ale już wówczas usuwaliśmy zagnieżdżone zależności, więc otrzymalibyśmy niepełne paczki. Zamiast tego po prostu zgarnialiśmy gotowe paczki z PyPI. A dlaczego nie budować ich na nowo ze źródeł? Pomijając fakt, że wydawało się to zbędne (wszak paczki na PyPI nie zawierają żadnego skompilowanego kodu), nie mieliśmy do tego dobrej infrastruktury w eclass.
Za inspiracją @hroncok, dziś przygotowałem nowe wersje paczek ensurepip, które budują wszystko ze źródeł. Co się zmieniło, i dlaczego warto dziś budować ze źródeł? Po pierwsze, nasz kod budowania PEP517 dorobił się możliwości wydobycia poprzednich paczek .whl. Po drugie, skoro usuwamy zagnieżdżone zależności z pipa i setuptools, to właściwie testujemy inny kod niż ten, który trafia do ensurepip — a myślę, że miałoby sens testowanie obydwu wariantów. Po trzecie, budowanie ze źródeł ułatwi nakładanie łatek, a w szczególności umożliwi użytkownikom łatwe dodawanie lokalnych łatek.
A skoro już się za to wziąłem, to przy okazji zaktualizowałem stan testów we wszystkich trzech paczkach (pip, setuptools i wheel — tego ostatniego potrzebujemy ze względu na testy). No i oczywiście, że trafiłem na padające testy w wersjach z zagnieżdżonymi zależnościami, i przypadkiem odkryłem błąd w #PyPy.
https://github.com/gentoo/gentoo/pull/42882 (tak, nadal tam jesteśmy)
https://github.com/pypy/pypy/issues/5306 -
A while ago, I've followed the example given by #Fedora and unbundled ensurepip wheels from #Python in #Gentoo (just checked — "a while ago" was 3 years ago). This had the important advantage that it enabled us to update these wheels along with the actual pip and setuptools packages, meaning new virtual environments would get fresh versions rather than whatever CPython happened to bundle at the time of release.
I had considered using our system packages to prepare these wheels, but since we were already unbundling dependencies back then, that couldn't work. So I just went with fetching upstream wheels from PyPI. Why not build them from source instead? Well, besides feeling unnecessary (it's not like the PyPI wheels are actually binary packages), we probably didn't have the right kind of eclass support for that at the time.
Inspired by @hroncok, today I've tried preparing new revisions of ensurepip packages that actually do build everything from source. So what changed, and why should building from source matter now? Firstly, as part of the wheel reuse patches, we do have a reasonably clean architecture to grab the wheels created as part of the PEP517 build. Secondly, since we're unbundling dependencies from pip and setuptools, we're effectively testing different packages than these installed as ensurepip wheels — and so it would be meaningful to test both variants. Thirdly, building from source is going to make patching easier, and at the very least enable user patching.
While at it, I've refreshed the test suite runs in all three regular packages (pip, setuptools and wheel — we need an "ensurepip" wheel for the last because of test suites). And of course, I hit some test failures in testing the versions with bundled dependencies, and I've discovered a random bug in #PyPy.
https://github.com/gentoo/gentoo/pull/42882 (yes, we haven't moved yet)
https://github.com/pypy/pypy/issues/5306 -
APScheduler + requests 遇到 OSError: [Errno 24] Too many open files 的問題
#apscheduler #bug #code #collection #flask #gc #gunicorn #pypy #pypy3 #python #requests #source #urllib #urllib3 #workaround
-
Ciekawostki o Pythonowym "limited API" i "stable ABI".
1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.
2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.
3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".
4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".
5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.
-
Some fun facts about #Python limited API / stable ABI.
1. #CPython supports "limited API". When you use it, you get extensions that are compatible with the specified CPython version and versions newer than that. To indicate this compatibility, such extensions use `.abi3.so` suffix (or equivalent) rather than the usual `.cpython-313-x86_64-linux-gnu.so` or alike.
2. The actual support is split between CPython itself and #PEP517 build systems. For example, if you use #setuptools and specify `py_limited_api=` argument to the extension, setuptools will pass appropriate C compiler flags and swap extension suffix. There's a similar support in #meson, and probably other build systems.
3. Except that CPython freethreading builds don't support stable ABI right now, so building with "limited API" triggers an explicit error from the headers. Setuptools have opted for building explicit about this: it emits an error if you try to use `py_limited_api` on a freethreading interpreter. Meson currently just gives the compile error. This implies that package authors need to actively special-case freethreading builds and enable "limited API" conditionally.
4. A some future versions of CPython will support "limited API" in freethreading builds. I haven't been following the discussions closely, but I suspect that it will only be possible when you target that version or newer. So I guess people will need to be building two stable ABI wheels for a time — one targeting older Python versions, and one targeting newer versions plus freethreading. On top of that, all these projects will need to update their "no 'limited API' on freethreading" conditions.
5. And then there's #PyPy. PyPy does not feature a stable ABI, but it allows you to build extensions using "limited API". So setuptools and meson just detect that there is no `.abi3.so` on PyPy, and use regular suffix for the extensions built with "limited API".
-
Do you maintain or contribute to a #Python package that includes a C extension? Would you like to run a fuzzer against it?
If so, let me know and I will run it, or help you to get it running.
The fuzzer is #fusil, which generates random code calling into your functions and methods. It's useful to check for crashes on invalid inputs or unexpected call patterns.
It has found about 50 crashes in #CPython, 20 in #PyPy, 6 in #Numpy etc.
#fuzzing #fuzzer #testing
See here:
https://github.com/devdanzin/fusil/issues/37 -
A cóż ja mogę teraz robić, w piątkowy wieczór?
Oczywiście, że wysyłam zgłoszenia do przypadkowych projektów #Python / #RustLang, prosząc o aktualizację wersji #PyO3 i nowe wydanie, po to, by móc wprowadzić wsparcie #PyPy 3.11 w #Gentoo. Bo, rzecz jasna, prawidłowy sposób rozwoju współczesnych paczek Pythona to przypadkowo przepisywanie ich fragmentów w Ruście, a potem ignorowanie konieczności aktualizowania zależności przez pół roku albo dłużej.
Tak, mówię o tych wszystkich paczkach, które w ogóle jeszcze nie wspierają PyO3 0.23.x.
A potem jeszcze przyjdą i powiedzą, że powinniśmy zostawić temat zależności i bezpieczeństwa autorom projektów.
-
What could I be doing right now, on a Friday evening?
Of course filing bugs on random #Python / #RustLang packages requesting a #PyO3 version update and a new release, to support #PyPy 3.11 in #Gentoo. Because obviously the right way to maintain modern Python packages is to rewrite random parts of them in Rust, then neglect updating their dependencies for half a year or more.
Yes, I'm talking about all the packages that don't even support PyO3 0.23.x yet.
And then they'll come and say that we should leave dependency management and security to upstreams.
-
Dobra wiadomość: jest łatka dla #PyO3 dla wsparcia #PyPy 3.11, więc ruszamy z aktualizacjami w #Gentoo do przodu.
Złe wiadomości:
1. Mówimy o #RustLang, więc każdą paczkę trzeba łatać z osobna.
2. Nie chcemy trzymać dziesiątek kopii tej samej łatki, więc chcemy ją ciągnąć z sieci. Niestety, nie możemy użyć oryginalnej kopii, bo modyfikuje pliki, których nie znajdziemy w archiwum crate.
3. No więc trzymamy własną kopię tej łatki, ograniczoną do dostępnych plików. Niestety, pasuje tylko do wersji 0.23.4, a że mnóstwo paczek Pythona używa 0.23.3, to mamy sporo aktualizowania. Ale przynajmniej w większości przypadków wystarczy podmienić cyferki na liście `CRATES`, i wykasować `Cargo.lock`.
4. …no chyba że dana paczka akurat wymusza dokładnie 0.23.3, albo używa 0.22.x bądź starszej wersji. Wtedy bez łatania `Cargo.toml` się nie obędzie.No ale idziemy do przodu. Tyle że warto jeszcze wspomnieć, że z paczek Pythona robi się coraz większy bajzel cyklicznych zależności, ale to już inna bajka.
