Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3.13 support #2608

Open
SnoopJ opened this issue May 9, 2024 · 3 comments
Open

Python 3.13 support #2608

SnoopJ opened this issue May 9, 2024 · 3 comments
Assignees
Labels
Milestone

Comments

@SnoopJ
Copy link
Contributor

SnoopJ commented May 9, 2024

Requested Feature

Sopel should support Python 3.13 when possible. 3.13 entered beta on 7 May and is now feature complete, so it's a good time to start tracking what's needed for support. 3.13.0 final is scheduled for October 2024, and release candidates are scheduled for late July and early September.

Problems Solved

No response

Alternatives

No response

Notes

Known problems:

  • required setuptools version needs to be updated to 66.0 or higher (usage of deprecated pkgutil.ImpImporter by setuptools.version)
  • greenlet (required by SQLAlchemy) does not yet support Python 3.13 (issue)
@SnoopJ SnoopJ added the Feature label May 9, 2024
@SnoopJ SnoopJ added this to the 8.1.0 milestone May 9, 2024
@SnoopJ SnoopJ self-assigned this May 9, 2024
@SnoopJ
Copy link
Contributor Author

SnoopJ commented May 19, 2024

It may merit a separate issue, but making a note while it's fresh in my mind from PyCon US where the steering council solicited maintainer help:

It would also be helpful to evaluate the impact of free threading on Sopel. Of course we cannot do this until we can run on 3.13 at all, so it's follow-up work.

@dgw
Copy link
Member

dgw commented May 19, 2024

I don't think it should break anything, but what we need to do depends on what kind of help they want. Benchmark comparisons of our package running on GIL-enabled and GIL-disabled builds?

For our own purposes, testing on no-GIL Python would be good to expose any operations that are technically thread-unsafe but blocked by the GIL in current CPython builds. (But I think we already have Locks and such around those places. Probably.)

@SnoopJ
Copy link
Contributor Author

SnoopJ commented May 20, 2024

Mostly I think it's a good stress test for upstream's benefit just to see if any wheels fall off the wagon. I doubt they will, but it's easy enough to give it a go.

I guess it would be nice to do a perf comparison (the build with --disable-gil can still have the GIL turned back on, so it's only one build to juggle), but that does almost certainly require some thought about what we would even measure (and how). I'd say perf eval is well worth splitting into a separate ticket if we end up wanting to see what the impact is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants