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
Hi all,
given the latest blow against exposing implementation details of CPython in
their C-API (see https://github.com/cython/cython/pull/5767 for the endless
story), I seriously start wondering if we shouldn't just define
"Py_BUILD_CORE" (or have our own "CYTHON_USE_CPYTHON_CORE_DETAILS" macro
guard that triggers its #define) and include the internal "pycore_*.h"
CPython header files from here:
https://github.com/python/cpython/tree/main/Include/internal
This would give us greater freedom in accessing all the implementation
details, so that we could directly integrate with those. We'd obviously
still need one or more fallback implementations for "stable CPython",
Limited API, PyPy and friends.
There's a risk, clearly, that these internals change even during point
releases. Maybe not a big risk, but not impossible either. We'd have to
deal with that and so would our users.
OTOH, having a single macro switch would make it easy for users to adapt if
something breaks on their side, and also easy to benchmark if it makes a
difference for their code.
We could also leave it off by default and simply allow users with high
performance needs to enable it manually. Or start by leaving it off until a
new CPython X.Y release has stabilised and its (used-by-us) internals have
proven not to change, and then switch it on for that release series. In any
case, having a single switch for this feels like it could be easy to handle.
What do you think?
Stefan
