I've heard that libraries using ctypes, cffi, or cython code of various sorts in the real world wild today does abuse the unfortunate side effect of CPython's implementation of id(). I don't have specific instances of this in mind but trust what I've heard: that it is happening.
id() should never be considered to be the PyObject*. In as much as code shouldn't assume it is running on top of a specific CPython implementation. If there is a _need_ to get a pointer to a C struct handle referencing a CPython C API PyObject, we should make an explicit API for that rather than the id() hack. That way code can be explicit about its need, and code that is just doing a funky form of identity tracking without using is and is not can continue using id() without triggering regressive behavior on VMs that don't have a CPython compatible PyObject under the hood by default. [who uses id() anyways?] -gps On Thu, Jan 17, 2019 at 2:26 AM Steven D'Aprano <st...@pearwood.info> wrote: > Disclaimer: I'm not a ctypes expert, so I might have this completely > wrong. If so, I apologise for the noise. > > The id() function is documented as returning an abstract ID number. In > CPython, that happens to have been implemented as the address of the > object. > > I understand that the only way to pass the address of an object to > ctypes is to use that id. Is that intentional? > > As I see it, there is a conflict between two facts: > > - that id() returns a memory address is an implementation detail; as > such users should not rely on it, as the implementation could (in > principle) change without notice; > > - but users using ctypes have no choice but to rely on id() returning > the object memory address, as of it were an offical part of the API. > > Implementations like PyPy which emulate ctypes, while objects don't have > fixed memory locations, will surely have a problem here. I don't know > how PyPy solves this. > > Have I misunderstood something here? > > > > -- > Steve > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
