Python < restriction of limited api extension

[replabrobin (Robin Becker)]

I maintain rl-accel · PyPI and have distributed wheels compiled with limited api 3.7; I now find that there are problems when used in python 3.13 and python 3.14.

Compiling with 3.13/3.14 fixes the issues for python 3.13/3.14, but seems to raise another issue when those are run in python < 3.13.

The wheels don’t have any upper limit on python so do I need to add a micro release which adds a python<3.13 requirement to prevent the older wheels being used by Python>=3.13.0.

If I do that and also add wheels based on limited api 3.13 can I assume that lower pythons will not use limited api 3.13 wheels?

It seems that limited api will suffer from breakages as the core gets more changes so this might be a more general problem in future.

[encukou (Petr Viktorin)]

What kind of problems are you seeing? Is it something we can fix?

If I do that and also add wheels based on limited api 3.13 can I assume that lower pythons will not use limited api 3.13 wheels?

Yes (in new installations). pip and similar tools should install the higher limited API.

[replabrobin (Robin Becker)]

I asked here about the issue here

C stable api PY_SSIZE_T_CLEAN error

I maintain an optional reportlab c extension rl-accel · PyPI It has been working fine in Python 3.7 - 3.12 when compiled as a stable api 3.7 extension. Problems were observed using this in 3.13 and 3.14 and I was advised that changes had made some commen macros behave differently. Compiling with a later python would improve things although speed might be reduced. I now observe the following error when using a Python 3.14/3.13 compiled extension with python <=3.12 File “/home/robin/devel/re…

I looked at the sources of 3.12.9 and 3.13.2 and see that PY_SSIZE_T_CLEAN seems to have no usage at all in the 3.13 code. So there’s no obvious way to allow PyArg_ParseTuple to work across the 3.12 - 3.13 boundary if compiled in 3.13. If I compile in <3.13 I see other errors related to refcounts etc in 3.13/3.14.

[replabrobin (Robin Becker)]

It seems I can fix my problem with a rather dangerous fix ie replace the ‘#’ using call to PyArg_ParseTuple with a call to _PyArg_ParseTuple_SizeT. This is obviously quite unsafe, but as I don’t need to recompile until another stable API change occurs perhaps it’s OK.