Guido van Rossum schrieb am 02.02.22 um 01:43:
It may be hard to imagine if you're working on Cython, which only exists
because of performance needs, but there are other things that people want
to test with the upcoming CPython release in addition to performance
I know. Cython (and originally Pyrex) has come a long way from a tool to
get stuff done to a dependency that a large number of packages depend on.
Maintainer decisions these days are quite different from those 10 years
ago. Let alone 20.
Let's just try to keep things working in general, and fix stuff that needs
to be broken.
On Tue, Feb 1, 2022 at 4:14 PM Stefan Behnel wrote:
I'd rather make it more obvious to users what their intentions are. And
there is already a way to do that – the Limited API. (and similarly, HPy)
Your grammar confuses me. Do you want users to be clearer in expressing
their intentions?
Erm, sort of. They should be able to choose and express what they prefer,
in a simple way.
For Cython, support for the Limited API is still work in progress, although
many things are in place already. Getting it to work completely would give
users a simple way to decide whether they want to opt in for a) speed,
lots of wheels and adaptations for each CPython version, or b) less
performance, less hassle.
But until that work is complete, we're stuck with the unlimited API, right?
And by its own statements in a recent post here, HPy is still not ready for
all use cases, so it's also still a pipe dream.
Yes. HPy is certainly far from ready for anything real, but even for the
Limited API, it's still unclear whether it's actually complete enough to
cover Cython's needs. Basically, the API that Cython uses must really to be
able to implement CPython on top of itself. And at the same time interact
not with the reimplementation but with the underlying original, at the C
level. The C-API, and especially the Limited API, were never really meant
for that.
As it looks now, that switch can be done after the code generation, by
defining a simple C define in their build script. That also makes both
modes easily comparable. I think that is as good as it can get.
Do you have specific instructions for package developers here? I could
imagine that the scikit-learn maintainer (sorry to pick on you guys :-)
might not know where to start with this if until now they've always been
able to rely on either numpy wheels or building everything from source with
default settings.
It's not well documented yet, since the implementation isn't complete, and
so, a bunch of things simply won't work. I don't remember if the buffer
protocol is part of the Limited API by now, but last I checked it was still
missing, so the scikit-learn (or NumPy) people would be fairly unhappy with
the current state of affairs.
But it's mostly just passing "-DCYTHON_LIMITED_API" to your C compiler.
That's the part that will still work but won't do (yet) what you think.
Because then, you currently also have to define "-DPy_LIMITED_API=..." and
that's when your C compiler will get angry with you.
Stefan
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/2UFG7IPKR77HQG36BZAUEUDJJKIGBSLE/
Code of Conduct: http://python.org/psf/codeofconduct/
