Add Python 3.13, 3.14, and free threaded 3.14t to the testing

[cclauss]

https://devguide.python.org/versions

[agronholm]

Is there any point in testing against 3.14t?

[cclauss]

Does anyone have the permissions to remove Required from the Python 3.7 tests?

Also, 3.8 and 3.9, which are also end of life?

On Python 3.14t if the free threading tests pass, then what is the harm?

[agronholm]

Does anyone have the permissions to remove Required from the Python 3.7 tests?
Also, 3.8 and 3.9, which are also end of life?

I should have the permissions to do that. I'm not sure where these are coming from though – I haven't worked much with Trio's CI.

On Python 3.14t if the free threading tests pass, then what is the harm?

The extra CI jobs aren't free in terms of computing capacity, and may delay other jobs from being started. I'd be willing to include 3.14t only if there's demonstrable benefit from doing so, but the nature of sniffio is such that free-threading doesn't really come into play.

[agronholm]

Correction: I don't seem to have the administrative privileges to turn off the required jobs.

[agronholm]

@A5rocks ping – retiring the old jobs is indeed in order.

[cclauss]

https://github.com/python-trio/sniffio/settings/rules/new?target=branch --> Require status checks to pass

• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

[agronholm]

https://github.com/python-trio/sniffio/settings/rules/new?target=branch --> Require status checks to pass

This gives me a 404.

[cclauss]

Given:

• https://github.com/search?q=repo%3Apython-trio%2Fsniffio%20threading&type=code and
• Add support for Python 3.13-3.14 and drop support EOL 3.7-3.9 #53 (comment) and
• Add support for Python 3.13 3.14 3.14t #54

I think that testing on free-threaded Python would be appropriate (it passes) but I have removed it for now.

[agronholm]

Actually, given that it uses thread-locals, testing against 3.14t could be justified. So, feel free to add it back.

[x42005e1f]

Actually, given that it uses thread-locals, testing against 3.14t could be justified. So, feel free to add it back.

But is this not already covered by CPython tests? And I do not see any use of threads in the sniffio tests.

[agronholm]

Actually, given that it uses thread-locals, testing against 3.14t could be justified. So, feel free to add it back.

But is this not already covered by CPython tests? And I do not see any use of threads in the sniffio tests.

CPython tests, as opposed to what? And I don't know about tests but sniffio does in fact use thread-locals, so 3.14t is borderline justifiable to test against.

[cclauss]

Can this be merged, or do those Required tags next to the Python 3.7 tests block merging?

[agronholm]

Can this be merged, or do those Required tags next to the Python 3.7 tests block merging?

[x42005e1f]

CPython tests, as opposed to what?

sniffio uses instances of the threading.local subclass. What is the purpose of testing them if the expected behavior is ensured by CPython tests?

[agronholm]

CPython tests, as opposed to what?

sniffio uses instances of the threading.local subclass. What is the purpose of testing them if the expected behavior is ensured by CPython tests?

We're not testing that threading.local() works, we're testing that nothing goes wrong with the way sniffio interacts with it.

[cclauss]

The current code uses the threading module. How do we guarantee that future changes will not use that module in ways that cause breakage on a free-threaded version of Python?

I would be happy to drop Python 3.14 (and 3.8, 3.9) and keep 3.14t as the safest path, which reduces the number of CI test runs.

[agronholm]

I would be happy to drop Python 3.14 (and 3.8, 3.9) and keep 3.14t as the safest path, which reduces the number of CI test runs.

I'd like other maintainers to share their opinions on that.

[A5rocks]

Does anyone have the permissions to remove Required from the Python 3.7 tests?

Done. I've kept 3.8 and 3.9 for now since they still work, but if anyone does the obvious followup and switches CI to use https://github.com/re-actors/alls-green (which we use in Trio for exactly this reason) I'll remove the others.

[A5rocks]

Another potential followup: setup-python supports -dev versions now, so this step can be removed.

(CI is sisyphean...)

[agronholm]

Do you intend to also get rid of those non-standard requirements files in favor of dependency groups? I'd be happy to send a PR.

[A5rocks]

I would be fine with that, yeah. (I hadn't exactly intended that since I had thought we were using pip-compile! But we're not, so...)