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 <steve at 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 at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190117/388ca470/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4