Lmst

[Перевод] 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/d3fb6b685e511bce4183b674dd171c9e710765d8.camel@gentoo.org/T/#u
https://public-inbox.gentoo.org/gentoo-dev/20241009115754.584070-1-mgorny@gentoo.org/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.

My weekend :python: 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

Output from running a randomized stress test on a CPU-bound synthetic test suite. “Ran 70 tests in 1.3 seconds, saving 10.6 seconds”

@__sharky__ @bouncing
As far as I understand, stuff like `setattr` or any sort of cache needs to be handled with care in multi-threading. Again, this is already true with the GIL, it's just that I never considered the possibility of my code running concurrently at all and #freethreading #Python just gave me the push I needed to think about it. I also maintain packages filled with C and Cython extensions, so I need to know this stuff anyway.

@bouncing no, you're right ! It’s just that my own pure Python libraries were *not* thread safe yet since I never considered it before.

Yet, #freethreading being marked as experimental (and overall brand new) I don't think it’d hurt to also test pure Python projects that already claim thread safety: you may discover the GIL was actually hiding bugs, or better yet, you might find edge cases where Python itself breaks.

Resources that helped me a lot getting started:

How to even get #freethreading #Python in CI, by @hugovk
https://dev.to/hugovk/help-test-python-313-14j1

and the dedicated blog by the Quansight team
https://py-free-threading.github.io/

Many thanks to the authors !

Getting my packages ready for #freethreading #Python (PEP 703) means I need to learn all-things-threads for the first time.
This wasn't obvious to me at first, but you can't just run your existing *single-threaded* tests suite: you also need to check how your objects behave in a multi-threaded context.
So you need new tests. Where should you even start ? A good strategy is to write tests around mutating methods. And boy am I glad that I already had an aversion for mutability.