Path: csiph.com!weretis.net!feeder8.news.weretis.net!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Salvo Tomaselli Newsgroups: linux.debian.maint.python Subject: Re: Involving free-threaded Python in Debian (Was: Free-threaded python3.13t packaging in Debian?) Date: Tue, 04 Nov 2025 10:10:01 +0100 Message-ID: References: X-Original-To: Chen Shengqi X-Mailbox-Line: From debian-python-request@lists.debian.org Tue Nov 4 09:03:36 2025 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.994 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-wm1-f51.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Forwarded-Encrypted: i=1; AJvYcCXw+ZFZKc8kpfhB1Q7p0uKSwEJx8nsgf6qciRqEWvBDfdIo8eMAaLG7FfFLspjGI3Q7wqK6orstYKk4n4XZ@lists.debian.org X-Gm-Message-State: AOJu0YyFJwQVKKKLo1btpBxaQKc54/dRbehyOtRbfM041j85OkPQwmP2 oRw5ZG7JiMgNaZr8aEVS7SVdIaXET7SBGBWm8mnktdp509lqKqg9RxJ0SAe+S/ki9U4jy9lyIJa ZlHlTldeB3lgCrMnNDUlFaEHRZ4PxiFg= X-Gm-Gg: ASbGnct6pkGjRL2mCtbk5BX1ytDjH750GkLRuPR4tJ9D7rIdjII81RdOFSlsNoiKXn+ jifLN6j99zFKXdsh9YTsq7er3aIqRKIT3QvOUMi85cQz5UGM2WIAyWScNlETTarBTGBU+I/bVDP YaThRplhrteLgD6kZZ5+Jzby1ZZMXa/+oSNmHaWVPbks9aQsyCu6e25Bp5g718XP0yCprCWqJ/G yNA46vvRMdSTolyyvrm3R0/ni4QsRnP0Uetlk7TMjhfcgVkYWNSXYu2lTb3tseCrLKROHaa2ov8 YKowg8SOd6ApF3dQ X-Google-SMTP-Source: AGHT+IExBbBsgl/LprksoT7l5GPCCWIuWtQZHXfTDW5zniGanSNUf41vH2uIsRyZr5P5a1NmGvcvlpEuqNRNwcXHXmU= X-Received: by 2002:a05:600c:828f:b0:46e:3d41:6001 with SMTP id 5b1f17b1804b1-477308a7b5emr178044155e9.34.1762246993476; Tue, 04 Nov 2025 01:03:13 -0800 (PST) MIME-Version: 1.0 X-Gm-Features: AWmQ_bmujT1jiqvKxPDue3VC6YQKbpJKZ_dIuUBiDeMMogkHjkrEgHJBezknIDM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/23325 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAOOnQAcid4-3Wi6Y9rL7d58USZtcEVB4s88ikNmQRWJ732JnXA@mail.gmail.com Approved: robomod@news.nic.it Lines: 142 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Salvo Tomaselli , Matthias Klose , Stefano Rivera , "debian-python@lists.debian.org" , "aron@debian.org" , "ben0i0d@foxmail.com" , Blair Noctis X-Original-Date: Tue, 4 Nov 2025 10:03:00 +0100 X-Original-Message-ID: X-Original-References: <3D4BF25C-7BC7-4DC3-8E3E-20D35A0BF4B7@outlook.com> <3054600.mvXUDI8C0e@galatea> Xref: csiph.com linux.debian.maint.python:17125 Hello, I would personally wait, but I of course won't prevent you from doing the work :) Just yesterday I was arguing with an upstream developer on ycombinator[1] because it seems that to support free threaded python they've basically reintroduced the GIL. The author seems to believe that there are two possible situations at the moment, lots of bugs or using a lock. I don't know if he's right of course. Anyway packages would need to provide multiple versions. I haven't thought about it too much but I think it would need to be 2 separate binary packages rather than the same package providing both versions (similar to when a python transition is in progress) because most non-pure python packages do not support free threading so for them the package should not exist, rather than exist and then fail at runtime. At this time I think it could make sense to maybe just provide the free threaded one, perhaps just in experimental, and then let users use pip/venv/whatever to get their dependencies. Just my opinion though. Best 1. https://news.ycombinator.com/item?id=3D45777133 Il giorno mar 4 nov 2025 alle ore 08:28 Chen Shengqi ha scritto: > > Hi, > > > Python 3.13 is released with experimental free-threaded (or no-gil) mod= e [1]. > > Upstream calls it python3.13t. I wonder whether Debian plans to package= it? > > Now we're in the forky cycle and Python 3.14 is out. Free-threaded interp= reter > is no longer experimental. Many useful packages, e.g. numpy, pandas, have= now > supported it [1]. So I think it is time for some discussion again. > Xu Chen mentioned that he had some previous email with Stefanor, so I'm l= ooping > him into this thread. > > Per Python documentation [2][3], the free-threaded version (python3.14t) = must > be built alongside the regular CPython (python3.14), along with its stand= ard > libraries. So we could treat it as yet another independent Python version= and > separately package it as python3.14t, python3.14t-stdlib, python3.14t-dev= , etc. > > The issue is now how to handle other Python packages (and also applicatio= ns), > especially those with native code (e.g. C or Rust extension), which requi= re > explicit opt-in to be used by 3.14t. Otherwise, GIL will still be enabled= . > > There are some possible options (maybe more?): > > (a) Let python3.14 and python3.14t share the same dist-packages dir, and = build all > python packages only for python3.14. When importing non-pure packages fr= om > dist-packages, python3.14t enables GIL. Users could choose freely from b= oth, > and benefit from nogil feature in their scripts and virtual environments= . > After unification of interpreters, we will need to rebuild all packages = with > free-threaded support anyway. > > This requires minimal effort from the toolchain maintainer now (looks lik= e Xu Chen > has already done some work on this) and still provides nogil option for u= sers. > Then we have to run a large transition on all python packages when free-t= hreaded > Python becomes default, which might happen around ~2028, in the next rele= ase cycle > > (b) Use separate dist-packages dir for python3.14 and python3.14t, and bu= ild all > python packages for both versions (e.g. python3-foo, python3t-foo). This= will > lead to extra maintainence work now: we need to modify pybuild to pass t= he > `Py_GIL_DISABLED` flag when building free-threaded versions; for pure Py= thon > packages, adding only one line of 'Provides' is enough; for complex soft= ware > like PyTorch, there might be more work. And I have not figured out a sol= ution > for packages that install executable files into bin. > > Such co-existence will surely put more burden on the archive, yet gives p= ackage > maintainers and users more time to test and adapt. Some system tools / pa= ckages > could have the boost brought by free-threaded Python. However this requir= es more > than one transition -- one to rebuild all packages for free-threaded Pyth= on, and > then remove all non-virtual python3t-foo packages. > > (c) Similar to (a), but build for python3.14t by default. > > This is somehow aggressive, as many packages are not ready yet. And I'm n= ot sure > what the behavior of GIL-enabled Python importing free-threaded packages = will be like. > This removes the need for a later transition or a large number of package= addition > / removal in the archive. > > What do you think? > > [1]: https://hugovk.github.io/free-threaded-wheels/ > [2]: https://docs.python.org/3.14/howto/free-threading-python.html#the-gl= obal-interpreter-lock-in-free-threaded-python > [3]: https://peps.python.org/pep-0703/ > > Thanks, > Shengqi Chen --=20 Salvo Tomaselli I difensori della morale tradizionale sono raramente persone di cuore. Si = =C3=A8 tentati di pensare che essi si servano della morale come di legittimo sfogo al loro desiderio di fare del male agli altri. -- Bertrand Russell, Perch=C3=A9 non sono cristiano. 1957 http://ltworf.github.io/