Ronald Oussoren via Python-Dev schrieb am 02.02.22 um 16:44:
On 2 Feb 2022, at 11:50, Stefan Behnel wrote:
Petr Viktorin schrieb am 02.02.22 um 10:22:
- "normal" public API, covered by the backwards compatibility policy (users
need to recompile for every minor release, and watch for deprecation warnings)
That's probably close to what "-DCYTHON_LIMITED_API" does by itself as it stands. I can
see that being a nice feature that just deserves a more suitable name. (The name was chosen because
it was meant to also internally define "Py_LIMITED_API" at some point. Not sure if it
will ever do that.)
- internal API (underscore-prefixed names, `internal` headers, things
documented as private)
AFAIK, only the last one is causing trouble here.
Yeah, and that's the current default mode on CPython.
Is is possible to automatically pick a different default version when building
with a too new CPython version? That way projects can at least be used and
tested with pre-releases of CPython, although possibly with less performance.
As I already wrote elsewhere, that is making the assumption (or at least
optimising for the case) that a new CPython version always breaks Cython.
And it has the drawback that we'd get less feedback on the "normal"
integration and may thus end up noticing problems only later in the CPython
development cycle.
I don't think this really solves a problem.
In any case, before we start playing with the default settings, I'd rather
let users see what *they* can make of the available options. Then we can
still come back and see which use cases there are and how to support them
better.
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/2SIGLMW4HNF5BDF2DTFZFXCHNSR4VAGB/
Code of Conduct: http://python.org/psf/codeofconduct/
