I'm very happy to announce @savannah as the Release Manager for Python 3.16 and 3.17!
https://discuss.python.org/t/welcome-the-3-16-and-3-17-release-manager-savannah-bailey/100163
#Python #CPython #Python316 #Python317

探索 CPython 3.14 的遠端偵錯協定
➤ CPython 3.14 遠端偵錯功能的實用指南
✤ https://rtpg.co/2025/06/28/checking-out-sys-remote-exec/
CPython 3.14 引入了一項新功能，允許將 Python 程式碼注入到正在運行的進程中，藉此簡化了遠端偵錯流程。過去，Python 的偵錯工具通常需要修改原始碼並重新啟動程式才能進行偵錯。現在，透過 `sys.remote_exec`，我們可以直接向運行的進程發送並執行程式碼，而無需重新啟動。此功能降低了偵錯工具開發的門檻，並提供了更便捷的偵錯體驗。
+ 終於不用為了偵錯而頻繁修改程式碼再重啟了，這真是太方便了！
+ 這個功能讓我想起以前用 gdb 偵錯 C++ 的日子，Python 終於也能做到類似的功能了。
#Python #偵錯 #CPython 3.14

Busy day, good day: the new CPython fuzzer lafleur found its first 2 crashes this morning!

Happiness only marred by the bad job I did reducing the testcases and making the reports reproducible. Thanks Brandt Bucher and and Ken Jin for the patience! Next bug reports will be more polished and reliable.

Also, we got 3 new PRs for the fuzzer but I didn't have time to review them, will have to leave that for tomorrow.

https://github.com/devdanzin/lafleur/

Thanks to everyone for taking part in the #CPython sprint at #EuroPython2025!

Across all CPython repos this weekend:

* 122 PRs created (69 the previous weekend)
* 79 PRs merged (65)
* countless invaluable in-person discussions (a few?)

Launching a new project on a Sunday night: lafleur, a CPython JIT fuzzer.

https://github.com/devdanzin/lafleur

It's a feedback driven fuzzer (using JIT debug output) with corpus prioritization and JIT-targeted AST-based mutations. Calling it "evolutionary" may be a stretch, but sounds good.

It's also a fuzzer that so far hasn't found any crashes or bugs. Still working on that ;)

If you want to understand how it works, there is a good amount of docs.

CPython — бессмертные Immortal объекты

Начиная с версии 3.12 Python поддерживает такой тип объектов, как бессмертные ( Immortal ). Бессмертными объектами являются глобальные константы, такие как None , False , True , а также некоторые другие объекты. Если вам интересно, что это за объекты, как ими становятся обычные смертные, где они используются и как повлияли на CPython — добро пожаловать.

https://habr.com/ru/articles/929228/

Trying real hard to build a fuzzer targeting the CPython JIT, lots of features implemented but not a single crash or bug discovered so far.

Such is life when hunting for crashes in robust code.

This weekend I'll be spinning off a new fuzzer that grew from fusil. Wish me luck

Diego Russo, Python Core Developer, is speaking about "Exploring the CPython JIT" in the main hall of EuroPython 2025

#EuroPython #EuroPython2025 #Python #CPython #JIT #Compilers

https://ep2025.europython.eu/session/exploring-the-cpython-jit

CC @europython

Reflections on 2 years of CPython's JIT Compiler: The good, the bad, the ugly

https://fidget-spinner.github.io/posts/jit-reflections.html

[Перевод] Самый быстрый способ нахождения гласной в строке

Недавно меня заинтересовала такая задача: как лучше всего определить, что в строке есть гласная? Казалось бы, тривиальный вопрос, правда? Но, начав разбираться, я осознал, что задача гораздо глубже. Я бросил себе вызов: придумать как можно больше способов обнаружения гласной. Я даже попросил присоединиться ко мне нескольких друзей. Какой способ самый быстрый? Каким никогда не стоит пользоваться? Какой самый умный? Какой самый удобочитаемый? В этом посте я рассмотрю 11 способов обнаружения гласных, алгоритмический анализ, дизассемблирование байт-кода Python, реализацию CPython и даже исследую опкоды скомпилированного регулярного выражения. Поехали!

https://habr.com/ru/companies/ruvds/articles/920932/

Как привинтить Python к Go

Здравствуйте, Меня зовут Александр Певзнер, и я программирую на Си и Go. Go обычно ассоциируется с бакендом, микросервисами и вот этим вот всем. Но я использую его необычным образом: я пишу на нём системное ПО. Почему я это делаю именно на Go? Этот язык привлекает меня своей простотой, лаконичностью, ясной семантикой, прекрасной документацией и великолепной стандартной библиотекой. Одна из моих программ, ipp-usb , написанная на Go, входит во все дистрибутивы Linux и *BSD и делает возможным использование принтеров и сканеров, которые подключаются к USB и поддерживают IPP over USB протокол - т.е., примерно всех современных. А еще я член OpenPrinting - небольшой, но очень плодотворной группы людей, которая ответственна за печать и, отчасти, сканирование на всех UNIX-like OS и за формирование индустриальных стандартов в этой области. Это всё начиналось для меня, как хобби, но сейчас это - часть моей оплачиваемой работы. В силу особенностей моей работы меня не очень интересуют такие вещи, как поддержка миллиона запросов в секунду и прочий high load (это не значит, что мои программы тормозные. Но никто не дёргает системный принтер миллион раз в секунду). Но зато приходится разбираться с некоторыми другими непростыми штуками. Об одной из таких штук и пойдёт речь в этой статье. Понадобился мне для одного проекта на Go встроенный скриптинг. Ну т.е., чтобы программа могла всосать в себя скрипт, который определяет некоторые аспекты её поведения. Размышляя о том, на каком языке программа должна скриптоваться, в выбирал между JS , Lua и Python . Однако, JS и Lua - слишком нишевые языки. JS ассоциируется у всех с вебом а Lua - с разработкой игр. Таким образом, выбор естественным образом пал на Python . Этот язык знают все, а я испытываю некоторую надежду, что скрипты для моей программы буду писать не только я. Хотя сам я, должен признаться, Python не знаю и не люблю :) Таким образом, осталось только придумать, как встроить интерпретатор Python -а в программу на Go . Об этом и пойдёт речь в этой публикации

https://habr.com/ru/articles/919590/

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