On 07. 12. 21 19:28, Guido van Rossum wrote:
On Tue, Dec 7, 2021 at 12:58 AM Petr Viktorin <encu...@gmail.com
<mailto:encu...@gmail.com>> wrote:
On 06. 12. 21 21:50, Guido van Rossum wrote:
[...]
> Also, it looks like Mark is proposing to *remove*
_PyObject_GC_Malloc
> from stable_abi.txt in
https://github.com/python/cpython/pull/29879
<https://github.com/python/cpython/pull/29879>
> <https://github.com/python/cpython/pull/29879
<https://github.com/python/cpython/pull/29879>> Is that allowed? If
it's
> being used by a macro it means code using that macro will fail
unless
> recompiled for 3.11.
Generally, that's not allowed. In this particular case, Victor's
analysis is right: if you trawl through the history from 3.2 on, you
can
see that you can't call _PyObject_GC_Malloc via macros in the limited
API. So yes, this one can be removed.
Okay, that's very subtle, so thanks for confirming.
I'll also note that removing things that are "allowed" to go is not
nice
to people who relied on PEP 384, which says that defining
Py_LIMITED_API
"will hide all definitions that are not part of the ABI" -- even though
that's incompatible with the part where it says "All functions starting
with _Py are not available to applications".
I don't actually really follow what you are trying to say here. Probably
because I've never paid much attention to PEP 384. I guess the API is
confusing because the "right" way to do it (having to define some symbol
to *expose* extra stuff rather than to *hide* stuff) was not possible
for backwards compatibility reasons. But the extra negative will forever
make this confusing. Also, "All functions starting with _Py are not
available" sounds like a clumsy way to say "No functions starting with
_Py are available" (and you left out whether Py_LIMITED_API affects that
availability, whether it was intended to affect it, whether it did in
practice affect it in all cases, etc.
It's hard to say what PEP 384 was meant to say. My interpretation, PEP
652, is hopefully more consistent. But someone who had a different
interpretation of PEP 384 might feel that it broke some promise.
I assume it would be insensitive to ask whether we could just get rid of
the stable ABI altogether and focus on the limited API? Just tell
everyone they have to rebuild binary wheels for every Python feature
release. Presumably the deprecation of the stable ABI itself would
require a two-release waiting period. But maybe it would be worth it,
given how subtle it is to do the historical research about even a single
function.
A honest question wouldn't be insensitive. Thanks for asking!
The part where you don't need to rebuild extensions (not just wheels) is
the main reason for both Stable ABI and the Limited API.
Without it, there might be some reduced API to focus on, but it wouldn't
be this feature.
_______________________________________________
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/SBQHQ6DWSXMDVQCETVDMRLZ3CNG4OJUL/
Code of Conduct: http://python.org/psf/codeofconduct/
