https://blog.gslin.org/archives/2025/06/23/12484/apscheduler-requests-%e9%81%87%e5%88%b0-oserror-errno-24-too-many-open-files-%e7%9a%84%e5%95%8f%e9%a1%8c/

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.

#Python

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".

🌗 RPython GC 的分配速度有多快？
➤ 深入分析 RPython 垃圾回收器的分配效率
✤ https://pypy.org/posts/2025/06/rpython-gc-allocation-speed.html
本文探討了 RPython 垃圾回收器 (GC) 的分配速度。作者透過一個簡單的基準測試程式，測量了在 64 位元架構上分配包含單一整數欄位的物件的效能。測試結果顯示，RPython GC 在沒有初始化欄位的情況下，可以以高達 34.35 GB/s 的速度分配物件，即使初始化欄位，也能達到 29.7 GB/s。作者將 RPython GC 的效能與 Boehm GC 進行比較，並使用 perf 工具分析了快取命中率、指令週期和分支等指標。研究發現，RPython GC 的分配速度非常快，且垃圾回收佔總執行時間的比例相對較小。
+ 這篇文章對於瞭解 RPython 垃圾回收器的效能非常有幫助，提供了詳細的測試數據和分析結果。
+ 我一直很好奇 PyPy 的效能，這篇文章讓我對 RPython
#程式設計 #垃圾回收 #PyPy #RPython #效能分析

W oczekiwaniu jutrzejszej Wielkiej Zmiany, przebudowuję mój kontener roboczy #Gentoo, wyłączając wsparcie Pythona 3.10 oraz #PyPy 3.10. 1158 paczek do przebudowania — i długa lista konfliktów. Tyle że nie wiem, czy te konflikty to "nie przebuduję tych paczek", czy tylko "poradziłem sobie z nimi".

#Python

In anticipation of tomorrow's Big Switch, I'm rebuilding my #Gentoo dev conainer with #Python 3.10 and #PyPy 3.10 disabled. 1158 rebuilds — and a long list of conflicts, though I'm not sure if these conflicts were "I won't rebuild these packages" or "I have resolved them".

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

Przypomnienie: 2025-05-01, #Gentoo przechodzi na Pythona 3.13, jako domyślną wersję.

Usuwamy również wsparcie budowania paczek dla Pythona 3.10 i #PyPy 3.10. W odróżnieniu od wcześniejszych migracji, przejście na PyPy 3.11 wymaga zmiany flag PYTHON_TARGETS.

Spodziewamy się również, że wersja beta CPythona 3.14 wyjdzie jakoś w połowie maja, i od tego momentu będziemy stopniowo dodawać wsparcie do paczek, w miarę dostępnego czasu.

https://public-inbox.gentoo.org/gentoo-dev/d43d6cbdadfd8c6c08e976b0a627c9ddd3c616c2.camel@gentoo.org/T/#u
https://www.gentoo.org/support/news-items/2025-03-24-python3-13.html

#Python

PSA: reminder that on 2025-05-01, #Gentoo is switching the default to #Python 3.13.

We are also removing the support for Python 3.10 and #PyPy 3.10 targets. Unlike the previous times, the upgrade to PyPy 3.11 now requires switching target flags.

We also do expect CPython 3.14 betas to land mid-May, and we will start adding relevant targets soon afterwards, as time permits.

https://public-inbox.gentoo.org/gentoo-dev/d43d6cbdadfd8c6c08e976b0a627c9ddd3c616c2.camel@gentoo.org/T/#u
https://www.gentoo.org/support/news-items/2025-03-24-python3-13.html

🇺🇦 #NowPlaying on #KEXP's #VarietyMix

PyPy:
🎵 Vanishing Blinds

#PyPy

https://pypy.bandcamp.com/track/vanishing-blinds

https://open.spotify.com/track/5ey8MNAoVM4Qg1gn2w7wO9

Jeden błąd w #PyPy naprawiony, i #IPython w #Gentoo jest na #PyPy 3.11.

Jeden błąd w bibliotece standardowej #Pythona naprawiony, #Django w Gentoo jest na PyPy 3.11.

Powiedziałbym, że całkiem udany dzień.

https://github.com/pypy/pypy/pull/5239
https://github.com/python/cpython/pull/130962

#Python

One #PyPy bug fixed, and #Gentoo gets #IPython on #PyPy 3.11.

One #Python stdlib bug fixed, and Gentoo gets #Django on PyPy 3.11.

I dare say that's a pretty good day.

https://github.com/pypy/pypy/pull/5239
https://github.com/python/cpython/pull/130962

Dear @ThePSF ...

having been engaged with #Python through co-creating #pytest #pypy, giving talks and trainings i appreciate that the PSF has long been a champion of diversity and inclusion! Are you aware that these days many non-USians are canceling their US travels? The German foreign ministry warns about travel to the US if you are pregnant or don't have your passport carrying a birth gender marker, then this: https://www.kpbs.org/news/border-immigration/2025/02/28/german-tourist-held-indefinitely-in-san-diego-area-immigrant-detention-facility

Maybe better update the #Pycon webpage accordingly?

Parę liczb: z 823 paczek ze wsparciem #PyPy 3.x w #Gentoo, 712 już doczekało się wsparcia PyPy 3.11. Zostało parę istotnych problemów do rozwiązania (m.in. IPython, z wieszającym się IPyParallel), i trochę paczek, które po prostu nie mają testów (więc jeszcze się im nie przyglądałem).

Co ciekawe, najczęstsze problemy z testami na PyPy 3.11 to:

• niestabilne testy (czyli trzeba uruchomić je jeszcze raz, najlepiej bez 70 innych paczek testowanych jednocześnie)
• istniejące, niezależne od wersji Pythona regresje (potwierdzone przez testowanie na CPythonie 3.11)
• istniejące problemy na PyPy 3.10 (wystarczy skopiować pomijane testy)
• nieistotne różnice, typu trochę inne komunikaty w wyjątkach

Poważne problemy to rzadkość, i zazwyczaj szybko są rozwiązywane (albo obchodzone przeze mnie). Naprawdę udane wydane! Wielkie podziękowania dla wszystkich, którzy pracują nad tematem!

Some fun numbers: out of 823 packages featuring #PyPy 3.x support in #Gentoo, 712 have already been ported to PyPy 3.11. There are a few significant blockers left (notably #IPython, with hanging IPyParallel), and a fair number of packages that simply don't have tests (so I haven't looked at them yet).

Interesting enough, the most common test failures seen while porting to PyPy 3.11 are:

• flaky tests (i.e. just need to rerun, especially without parallelization of testing 70 packages simultaneously)
• existing, irrelevant test regressions (i.e. confirmed by testing with CPython 3.11)
• existing test problems with PyPy3.10 (i.e. need to copy deselects)
• some minor differences, such as slightly different exception messages

Serious issues are really rare, and they are often fixed (or worked around by me) promptly. Really great release! Thanks to everyone involved!

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.

Low Overhead Allocation Sampling with VMProf in PyPy's GC — https://pypy.org/posts/2025/02/pypy-gc-sampling.html
#HackerNews #LowOverheadSampling #VMProf #PyPy #GC #MemoryManagement #PerformanceOptimization

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.

#Python

Good news is, there's an upstream patch for #PyO3 to support #PyPy 3.11, so the #Gentoo updates are progressing.

Bad news:

1. Since it's #RustLang, we need to patch every single package separately.
2. To avoid keeping a dozen copies of the same patch, we'd like to fetch it. Unfortunately, we can't use upstream pull request directly since it edits a bunch of files that aren't in the crate.
3. Ok, so we host a modified patch and we're good here. Unfortunately, the patch doesn't apply cleanly to the previous minor release (0.23.3), so we need to manually update PyO3 in a lot of #Python packages. Good news is, that's usually updating our `CRATES` list and removing `Cargo.lock`.
4. …except for these packages that pin exactly to 0.23.3, or are still on 0.22.x or earlier. Then we also need to patch `Cargo.toml`.

But yeah, things are going forward. And then of course Python packages are becoming an increasingly convoluted mess of cyclic dependencies, but that's another story.