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

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

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