Run CI for Python 3.14 free-threading #20029

cdce8p · 2025-10-08T08:19:22Z

No description provided.

cdce8p · 2025-10-08T10:22:23Z

test-requirements.in

 attrs>=18.0
 filelock>=3.3.0
-lxml>=5.3.0; python_version<'3.15'
+lxml>=5.3.0; python_version<'3.14'  # lxml doesn't ship wheels for cp314t yet


This could be updated if PEP 780 get's accepted. It's still a draft though at the moment.
https://peps.python.org/pep-0780/#examples

Hopefully lxml will have a free-threaded release out soon. My next task today is to run the lxml tests under TSan to hopefully validate a final set of fixes.

cdce8p · 2025-10-08T10:37:03Z

Looks like there is just one flaky test for the free-threading build.

mypy/test/teststubgen.py::StubgenPythonSuite::stubgen.test::testImportedModuleHardExits_import

ngoldbaum · 2025-10-17T19:07:32Z

Hi! I missed this and opened #20076. I think the failing test in the CI will be fixed when Python 3.14.1 comes out. The issue is fixed in the 3.15, 3.13, and as of yesterday also the 3.14 development branch.

The 3.14 release schedule says we might have to wait until December for 3.14.1, so it might make sense to simply skip the failing tests for now.

emmatyping · 2025-10-17T20:49:58Z

The 3.14 release schedule says we might have to wait until December for 3.14.1, so it might make sense to simply skip the failing tests for now.

I think this makes sense. I'd normally suggest we do a sys.version_info == (3, 14, 0)), but I don't think that can be encoded in our test harness at the moment.

cdce8p · 2025-10-18T11:00:57Z

The 3.14 release schedule says we might have to wait until December for 3.14.1, so it might make sense to simply skip the failing tests for now.

Normally I'd agree. However it might be a bit more difficult. AFAICT it's not just one test but up to 5-10 different ones (?) which are failing each time. Not sure I'm comfortable with skipping this many.

Yes, December is still two months away, however users are still able to use the pure Python version so there is at least an option for them. Technically they could also compile mypy from the sdist themselves. It might be better to just wait and add the free-threading version then.

cdce8p · 2025-12-03T07:26:56Z

@ngoldbaum Looks like lxml is the only issue left. Any updates?

If not we could either not install lxml for 3.14 or check if the GIL is disabled with sys. _is_gil_enabled before running the lxml tests. https://docs.python.org/3/library/sys.html#sys._is_gil_enabled

ngoldbaum · 2025-12-03T14:08:21Z

See lxml/lxml#477 (comment) for the latest update on lxml. Thanks for working on this!

ngoldbaum · 2025-12-03T14:30:18Z

mypy/report.py


 try:
-    from lxml import etree  # type: ignore[import-untyped]
+    if sys.version_info >= (3, 14) and not sys._is_gil_enabled():


The GIL can be re-enabled on the free-threaded build by importing an extension that doesn't declare support for running without the GIL.

What matters here is the ABI, not whether the GIL is enabled at runtime.

Instead of sys._is_gil_enabled(), I'd use not bool(sysconfig.get_config_var("Py_GIL_DISABLED)). Future Python versions will have sys.abi_flags to get information like this.

👍🏻 Pushed a new commit.

Ideally I'd prefer to just not install lxml at all for free-threading builds but that's not supported yet. There was some progress on the packaging PEP but it might have stalled out again unfortunately.

I'm working with @zklaus on the packaging PEP! It's hard to make packaging changes but he's working on it still.

mypy/test/testcmdline.py

github-actions · 2025-12-03T15:41:47Z

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅