[Cython] Ready for Cython 3.1 ?

[Stefan Behnel]

Hi all,

it looks like Cython 3.0.6 is going to be a "most things fixed" kind of 
release for the 3.0.x release series. Given the work that lies ahead of us 
for Cython 3.1, I think we're at a point to get started on that, making the 
future 3.0.x releases stable and "boring".


As a reminder, Cython 3.1 will remove support for Python 2.7 and Python 
3.[567], i.e. all Python versions that are now EOL. Python 3.8 will 
continue to receive security fixes for another year. Python 3.7 is EOL but 
still up for debate since it's probably not hard to support and still 
maintained in some Linux distributions for another couple of years. But I'm 
fine with considering it legacy. We'll probably notice if it gets in the 
way while preparing Cython 3.0, and can leave support in until there's a 
reason to remove it.


https://github.com/cython/cython/issues/2800

I'd like to ease our feature development by using more modern Python 
features in our code base and by targeting less Python versions in Cython 
3.1 compared to the "all things supported" Cython 3.0.


I also consider Cython 3.1 a prime target for better Limited API support. 
Users probably won't care both for that and for outdated Python versions at 
the same time. Or, they can use Cython 3.0.x for continued legacy support.


Since Cython 3.1 is mostly about ripping out old code, we can try to keep 
the development cycle short, so that new features don't have to wait that 
long. Certainly not as long as for Cython 3.0…


Is everyone and everything ready to start working on Cython 3.1?

Stefan
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Should we start using the internal CPython APIs?

[Stefan Behnel]

da-woods schrieb am 04.11.23 um 14:45:

I'm a bit late in replying to this but here are some unordered thoughts.

* I'm fairly relaxed about using `Py_BUILD_CORE` if useful - I think we 
mostly do have good fallback paths for most things so can adapt quickly 
when stuff changes.


I'm not entirely relaxed about it, but I agree that the fallbacks should 
usually make it easy to keep things working also after larger changes in 
CPython.



* CYTHON_USE_CPYTHON_CORE_DETAILS sounds reasonable, but it's yet another 
variation to test.


True.


* I wonder if fixing up the limited API implementation should be higher 
priority than creating a third level been "full" and "limited API".


I think there's potential for all three. Basically modes "aggressively 
fast", "highly compatible" and "version independent". The latter is what 
the Stable ABI together with the Limited API should give you.



* I recall we were planning to ditch c89 as a strict requirement after 3.0? 
Incompatibility with C++ might be more of an issue though.


Yes. C++ is not an issue for CPython, so their internal header files are 
not tested with C++ at all. That's the highest potential for breakage, if 
we accept to generate C99 from Cython 3.1 onwards.


We should make sure that we use "-std=c89" in at least one Cython 3.0 test 
setup, BTW.



* Even so, if there's a good way of turning it off then we could say: "if 
you want strict c89 support then you can't use 
CYTHON_USE_CPYTHON_CORE_DETAILS" and people would always have options.


That could be part of it, yes.



* Waiting and seeing may be a good option for now.


I agree. This still seems best for now, especially given the amount of 
recent changes in the C-API. Let's wait for those to settle down, at least.


Thanks everyone for your opinions and comments!

Stefan

___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel