3.13 support

[clin1234]

The last officially-supported Python 3.7 release is close to a year ago, and 3.13 just had a beta release, meaning no new features will be added. Also setup-python supports 3.13.

[Avasam]

#2207 (comment)

[...] it would be ideal if I could make another final release supporting [3.7] given it went EOL after the most recent pywin32 release.

If dropping 3.7 is really necessary, this may have to wait for the next release, otherwise you might wanna keep Python 3.7 support to get this merged in sooner once the build passes.

[clin1234]

LGTM, so far just need to resolve _PyLong_NumBits

[mhammond]

As @Avasam said, I'd prefer to keep 3.7 until the next release

[clin1234]

As @Avasam said, I'd prefer to keep 3.7 until the next release

Amended.

[mhammond]

This looks great, thanks - I'll merge it once that conflict is resolved.

[mhammond]

(well, after the conflict and CI is green :) The "checkers" job will probably be fixed by rebasing on main.

[Avasam]

We're gonna need something like python/cpython#119418 to go through before the 3.13 build passes.

[mhammond]

We're gonna need something like python/cpython#119418 to go through before the 3.13 build passes.

Fair enough, but there's no point merging this until we do, right?

[Avasam]

Fair enough, but there's no point merging this until we do, right?

Imo, correct in the PR's current state.*
Since cpython is offering a solution (that should be backported to 3.13), the best thing to do is "just wait" (unless someone can come up with a better implementation than using _PyLong_NumBits)

I wouldn't want to merge this with failing 3.13 CI as that'll be very noisy.

* This PR still removes deprecated symbols, which is a good change on its own. Just not with a failing Python 3.13 CI.

[Avasam]

For the removed unittest.makeSuite, I think you can juste replace it with unittest.defaultTestLoader.loadTestsFromTestCase

[Avasam]

Nice! The build and tests pass. All you need to do to get the last check green is run black .
(I can't personally comment on whether the C code changes are completely accurate)

[clin1234]

Now that python/cpython#119336 has been resolved, please merge

[Avasam]

I'm not sure how you ended up adding that many past commits outside your changes. And I don't know if a rebase can save this at this point. After fixing conflicts, you might wanna consider a soft reset to bring all your changes from main into a single commit:

git fetch
git reset --soft upstream/main

validate that all changes are yours and intended (ie not due to a bad merge). stage, commit, then

git push --force-with-lease

[Avasam]

beta-2 for github actions was released ~11h ago: https://github.com/actions/python-versions/releases/tag/3.13.0-beta.2-9442465578

But you might have to wait for this issue to be resolved first anyway: actions/setup-python#886

[clin1234]

beta-2 for github actions was released ~11h ago: https://github.com/actions/python-versions/releases/tag/3.13.0-beta.2-9442465578

But you might have to wait for this issue to be resolved first anyway: actions/setup-python#886

CI PASSES! 😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁

[Avasam]

@mhammond I can't comment on PyObject_CallObject usage. But otherwise this now looks mergeable to me! Would be nice to have Python 3.13 support before next release.

[mhammond]

Thank you both!