Skip to content

Update Python version requirements to 3.12 and above, and add support for 3.14 #233

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Update Python version requirements to 3.12 and above, and add support for 3.14 #233

wants to merge 5 commits into from
+145 −287

Conversation

tobiasdiez
Copy link
Contributor

@tobiasdiez tobiasdiez commented Sep 19, 2025 •
edited
Loading

@tobiasdiez tobiasdiez marked this pull request as draft September 19, 2025 11:06
@cxzhong
Copy link

cxzhong commented Sep 23, 2025

maybe you should remove macos-13 from ci. Because macos-13 runners will be Deprecated in this November

@cxzhong
Copy link

cxzhong commented Sep 23, 2025

And there are two versions of python 3.14. one version is no gil, python3.14t, I think we can add this

@tobiasdiez
Copy link
Contributor Author

Thanks. Before going forward with this PR, 3.14 actually needs to be released.

@tobiasdiez tobiasdiez changed the title Update Python version requirements to 3.11 and above, and add support for 3.14 Update Python version requirements to 3.12 and above, and add support for 3.14 Sep 30, 2025
@tobiasdiez tobiasdiez mentioned this pull request Sep 30, 2025
Open
@tobiasdiez
Copy link
Contributor Author

tobiasdiez commented Sep 30, 2025 •
edited
Loading

Currently hitting #232.

@user202729 this looks like a fun issue made for you? 🦊

@tobiasdiez tobiasdiez mentioned this pull request Sep 30, 2025
Open
@tobiasdiez
Use Py_REFCNT over ob_refcnt for reference count checks
e8172b4 
Fixes

```
FAILED: [code=1] src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/meson-generated_src_cysignals_signals.pyx.c.o
cc -Isrc/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p -Isrc/cysignals -I../src/cysignals -Isrc -I../src -I/opt/_internal/cpython-3.14.0rc2-nogil/include/python3.14t -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -O3 -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -fPIC -pthread -MD -MQ src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/meson-generated_src_cysignals_signals.pyx.c.o -MF src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/meson-generated_src_cysignals_signals.pyx.c.o.d -o src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/meson-generated_src_cysignals_signals.pyx.c.o -c src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/src/cysignals/signals.pyx.c
src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/src/cysignals/signals.pyx.c: In function ‘__pyx_f_9cysignals_7signals_verify_exc_value’:
src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/src/cysignals/signals.pyx.c:4699:32: error: ‘PyObject’ {aka ‘struct _object’} has no member named ‘ob_refcnt’
4699 | __pyx_t_1 = (cysigs.exc_value->ob_refcnt == 1);
| ^~
src/cysignals/signals.cpython-314t-x86_64-linux-gnu.so.p/src/cysignals/signals.pyx.c:4996:33: error: ‘PyObject’ {aka ‘struct _object’} has no member named ‘ob_refcnt’
4996 | __pyx_t_10 = (cysigs.exc_value->ob_refcnt == 1);
| ^~
```
@user202729
Copy link
Contributor

or I can just not upgrade to Python 3.14 and not encounter the issue 🙈

more seriously, cysignals does use a lot of implementation-defined behavior, but it is somewhat surprising to see internal change to e.g. Python object struct or such breaking its behavior.

speaking of the most recent commit, if sagemath/sage#40734 gets in then sig_check would no longer be necessary for sage itself (downstream may still use it, but sig_check has a few disadvantages, one is it may call gc.collect() so you really don't want to call it in a tight loop and especially not in the destructor of something that may have a few hundred instances created such as Integer, another is it can be unreliable in the presence of reference cycles i.e. it will err too much on the side of caution in that case, keep reporting True and try to gc.collect(), but anyway this is the topic of #215 (comment) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@tobiasdiez @cxzhong @user202729