Add support for Python 3.13

[hugovk]

Summary

Python 3.13 was released in October:

• https://devguide.python.org/versions/
• https://peps.python.org/pep-0719/

Let's add it to the CI and classifiers.

Python 3.8 went EOL at the same time, shall we drop support for that too?

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[zanieb]

Why did this change? I don't think it should?

[hugovk]

It was so I could run the CI on my feature branch and be confident it passes before opening a PR.

[zanieb]

👍 could you revert it? I think this should be covered by the pull_request target.

[zanieb]

Separately, we could add a workflow_dispatch trigger so it can be invoked on fork branches manually?

[hugovk]

Yeah, happy to revert it. It just means next time I'll either make my changes directly on my main (not recommended) or not bother contributing (also not recommended :)

pull_request alone doesn't cover it: if I push changes to my fork, the CI won't run.

workflow_dispatch is good to have anyway, but I don't want to have to manually and tediously click buttons to trigger builds each and every time.

[zanieb]

Usually I just open a pull request in my fork for CI if I need to test it before opening a real pull request.

I'm not sure exactly what the conditions cause this, but having push without a filter and pull_request can run jobs twice on each pull request commit e.g. astral-sh/python-build-standalone@accb28c

[hugovk]

Yeah, creating a PR in your own fork is possible, it's still an extra impediment to contribution. This project's contribution guidelines shown how to test locally, which is good.

But we get all these free CI minutes, I'm a big fan of CIs, and my opinion is we should encourage people to test on CI and make it easy for them. No "works on my machine". Let me easily test all the Python version, all the operating systems, all the build steps in a clean CI environment. Let's have good "DX".

And it's possible to add config to prevent those double runs on upstream, I can look it up if you like.

Anyway, I've reverted this change.

[zanieb]

And it's possible to add config to prevent those double runs on upstream, I can look it up if you like.

I'm open to a proposal. My main reactions are that it doesn't belong in this pull request / limiting to the main branch is the standard pattern in all the repositories I work in. I agree making it easy for developers to test in CI is nice though :)

[zanieb]

Some prior discussion of 3.8 in #3419 (comment)