[Перевод] Python 3.14 без GIL: что это значит для веб-разработки

Команда Python for Devs подготовила перевод статьи о том, как "free-threaded" Python меняет правила игры для веб-сервисов. Автор сравнивает Python 3.14 с GIL и без него на реальных ASGI и WSGI приложениях — и приходит к неожиданному выводу: несмотря на локальные просадки в производительности, "free-threaded" Python уже сейчас может упростить масштабирование и снизить накладные расходы.

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

#Python #GIL #freethreading #вебсервисы #ASGI #WSGI #производительность #конкурентность #Granian #FastAPI

Python 3.14 will officially support free-threading

https://docs.python.org/3.14/whatsnew/3.14.html#pep-779-free-threaded-python-is-officially-supported

#HackerNews #Python314 #FreeThreading #Programming #News #PythonDevelopment #PEP779

There are on-going efforts to make Python free-threaded to eventually get rid of the GIL.
I'm curious and will follow the further progress. This would make the language and runtime even better than it is already.

For the current state, see https://pyfound.blogspot.com/2025/06/python-language-summit-2025-state-of-free-threaded-python.html.

#Python #FreeThreading #GIL

Projekt #PyYAML odrzucił wsparcie dla Pythona bez GIL (#freethreading). Skutkiem tego, powstał fork skupiony na dodaniu tego wsparcia. Ze względu na ograniczone potrzeby forka, wspiera on tylko Pythona 3.13+. A że nie da się jeszcze wyrażać zależności warunkowo od wersji freethreading, inne paczki wymagają PyYAML-ft dla wersji Pythona >=3.13 (w tym zwyczajnej, z GIL-em) i zwykłego PyYAML dla <3.13.

Czy świat paczek Pythona nie jest super?

https://github.com/yaml/pyyaml/pull/830#issuecomment-2342475334
https://github.com/Instagram/LibCST/blob/18d4f6aded907bd11b683fa54dad32ca04f84f75/pyproject.toml#L21-L24

#Gentoo #Python

#PyYAML rejected #freethreading support. As a result, a new fork has been created with freethreading support. Given the fork's focus on freethreading, it supports only Python 3.13+. Given the lack of environment markers for freethreading (yet), packages end up depending on PyYAML-ft for >=3.13 (including non-freethreading builds), and PyYAML for <3.13.

Isn't #Python #packaging great?

https://github.com/yaml/pyyaml/pull/830#issuecomment-2342475334
https://github.com/Instagram/LibCST/blob/18d4f6aded907bd11b683fa54dad32ca04f84f75/pyproject.toml#L21-L24

#Gentoo

[Перевод] Состояние производительности Python 3.13: Free-Threading

CPython 3.13 был выпущен две недели назад и стал одним из наиболее сфокусированных на производительности релизов за последнее время. Пробежавшись по release notes, я заметил несколько фич, которые могли бы повлиять на производительность. В этой статье мы сфокусируемся на free‑threaded режиме и посмотрим, как его использовать и как он может влиять на производительность.

https://habr.com/ru/companies/beget/articles/857724/

#python #freethreading

Zacząłem prace nad dodaniem wsparcie wersji #FreeThreading CPythona 3.13 do #Gentoo (tzn. technicznie już mieliśmy, ale jest zepsute). Rozszerzenia w tej wersji są niezgodne na poziomie ABI ze standardowymi, więc musimy ją zrobić odrębnie — włącznie z nową flagą PYTHON_TARGETS. W sumie ma to sens, bo i tak wypadałoby to osobno testować.

Koniec końców, teraz już rozważam spore zmiany w tym, jak #CPython jest paczkowany w Gentoo. Pokrótce, podążając za starymi zwyczajami, wersja freethreading by wylądowała jako:

dev-lang/python-3.13.0-r100:3.13t

Tyle że Portage upiera się, by zawsze instalować (dodatkowo) najnowszą wersją; nawet wówczas, kiedy wszystkie zainstalowane paczki akceptują wyłącznie wcześniejsze wersje (no cóż, czasem to ma sens). Tak więc wszyscy użytkownicy systemów ~arch dostaliby tę wersję zainstalowaną z automatu! Tak więc pomyślałem, żeby zamiast tego dać:

dev-lang/python-freethreading-3.13.0:3.13t

Ale jak się zastanowić, to problem niepożądanych aktualizacji nie jest niczym nowym. Kiedy dodawaliśmy pierwsze wersje 3.13, były instalowane użytkownikom ~arch z automatu, mimo że ich PYTHON_TARGETS nie wskazywał tych wersji. To samo użytkownicy stabilnej gałęzi, kiedy 3.13 w niej wyląduje. W gruncie rzeczy, mogło to doprowadzić do problemów, jeżeli ktoś używał własnych skryptów, które korzystały z systemowych paczek — zależności były zainstalowane dla 3.12, a tu nagle `python` zaczyna używać 3.13!

Poniekąd ten problem rozwiązaliśmy, dodając dev-lang/python-exec-conf, które instaluje domyślną konfigurację dla python-exec w oparciu o wybrane PYTHON_TARGETS. Ale dlaczego nie wziąć się za prawdziwy problem i pozbyć się łączenia wszystkich wersji w jedną paczkę ze slotami? Tak więc zaproponowałem, że kolejna wersja trafi w Gentoo jako:

dev-lang/python3_14

A skoro już zmieniamy, to może od razu pójść w "python3_13t" zamiast "python-freethreading"? Może nazwa mniej oczywista, ale przynajmniej wprost pokrywa się z PYTHON_TARGETS.

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

I've started working on adding the #FreeThreading version of #CPython 3.13 to #Gentoo (properly, our previous approach no longer works). Since it's not ABI-compatible with the regular 3.13, we need to make it truly separate — including a new PYTHON_TARGETS flag. Which kinda makes sense, because we'd want to test it explicitly anyway.

One thing lead to another, and now I'm considering major changes to how to we package CPython itself in Gentoo. Long story short, per the current custom we'd be adding the freethreading variant as something like:

dev-lang/python-3.13.0-r100:3.13t

However, because of Portage always insisting on additionally having the newest version installed anyway when only older slots are requested (well, in some scenarios this makes sense, I guess), this would mean all ~arch users would inadvertently get it installed! So I wanted to go for something like this instead:

dev-lang/python-freethreading-3.13.0:3.13t

But in fact, the inadvertent upgrades problem isn't really new. When Python 3.13 was added, ~arch people got it installed, even though their PYTHON_TARGETS didn't want it. Same goes for stable users when it gets stabilized. In fact, this used to lead to breakage when someone used custom scripts that relied on system #Python packages. Just imagine you've got all your dependencies installed for 3.12, and Portage suddenly installs 3.13 and `python` starts calling it by default!

Historically, we've kinda solved that problem by adding dev-lang/python-exec-conf that'd install a default configuration for python-exec that matched PYTHON_TARGETS. However, why not address the deeper issue and stop slotting instead. So I've proposed that going forward, we make them:

dev-lang/python3_14

And since I'm proposing a major change like this, why not go for "python3_13t" instead of "python-freethreading"? Perhaps it's less obvious, but has the advantage of matching PYTHON_TARGETS.

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

My weekend  project was building a new tool for Python projects, called “unittest-ft”, to run your entire test suite in parallel using a thread pool. With Python 3.13 and free threading enabled, this can dramatically speed up your test suite, as well as help catch any thread-safety issues that your project might have.

It also includes options to run "stress tests" which queues every test to be run ten times rather than just once, as well as randomizing the test order every time to help catch unintended test order dependencies.

This is intended for use with Python 3.13 or newer with free threading enabled, but is functionally useful back to Python 3.8 for testing and use in CI (it just won't be *faster* without FT).

https://pypi.org/project/unittest-ft/

#Python #FreeThreading #NoGIL