Victor Stinner schrieb am 24.06.20 um 02:14: > Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit : >>> Members of ``PyObject`` and ``PyTupleObject`` structures have not >>> changed since the "Initial revision" commit (1990) >> >> While I see an advantage in hiding the details of PyObject (specifically >> memory management internals), I would argue that there simply isn't much to >> improve in PyTupleObject, so these two don't fly at the same level for me. > > There are different reasons to make PyTupleObject opaque: > [Some reeasons why *PyObject* should not be exposed] > > * Prevent C extensions to make assumptions on how a Python > implementation stores a tuple. Currently, C extensions are designed to > have best performances with CPython, but it makes them run slower on > PyPy. > > * It becomes possible to experiment with a more efficient PyTypeObject > layout, in terms of memory footprint or runtime performance, depending > on the use case. For example, storing directly numbers as numbers > rather than PyObject. Or maybe use a different layout to make > PyList_AsTuple() an O(1) operation. I had a similar idea about > converting a bytearray into a bytes without having to copy memory. It > also requires to modify PyBytesObject to experiment such idea. An > array of PyObject* is the most efficient storage for all use cases.
Note, I understand the difference between ABI and API. Keeping PyTuple_GET_ITEM() a macro or inline function can break the ABI at some point once PyTupleObject changes in an incompatible way in Py3.14, and it may do different things in PyPy entirely at some point. That's fine. We have a policy of allowing ABI breakage between CPython minor releases. But this does not mean that PyTupleObject needs to become an opaque type that requires a function call into CPython for PyTuple_GET_ITEM(). It *may* become that at some point, when there is a reason to change it into a function call. In the current implementation, there is no such reason. In a future implementation, there may or may not be a reason. We do not know that. As of now, we're just needlessly slowing down existing code by disallowing the C compiler to see that PyTuple_GET_ITEM() literally just does a single pointer dereference. This applies ten-fold to types like PyLong and PyFloat, where getting straight at the native C value is also just a pointer dereference. Basically, what I'm asking is to keep things as efficient as they are *in CPython* as long as there is no reason to change them *in CPython*. >> If we remove CPython specific features from the (de-facto) "official public >> Python C-API", then I think there should be a "public CPython 3.X C-API" >> that actively exposes the data structures natively, not just an "internal" >> one. That way, extension authors can take the usual decision between >> performance, maintenance effort and platform independence. > > I would like to promote "portable" C code, rather than promote writing > CPython specific code. > > I mean that the "default" should be the portable API, and writing > CPython specific code would be a deliberate opt-in choice. That's what I mean by "public CPython 3.X C-API". Don't discourage its use, don't hide away details. Just make it clear what is CPython specific and what isn't, but without judging. It's a good thing for extensions to be fast on CPython. >> I haven't come across a use >> case yet where I had to change a ref-count by more than 1, but allowing >> users to arbitrarily do that may require way more infrastructure under the >> hood than allowing them to create or remove a single reference to an >> object. I think explicit is really better than implicit here. > > Py_SET_REFCNT() is not Py_INCREF(). It's used for special functions > like free lists, resurrect an object, save/restore reference counter > (during resurrection), etc. Exactly, so it is Py_INCREF() or Py_DECREF(), just without side-effects. I'm arguing that the use case is also practically the same: increase or decrease the refcount of an object, but without triggering the deallocation machinery. Now read my paragraph above again. :) Is it too late in the Py3.9 cycle to switch to two separate macros? 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/K7YQLIWPTEHPH7KTEFGN6ALH2SN6U6YJ/ Code of Conduct: http://python.org/psf/codeofconduct/
