On 2019-01-18 00:48, Gregory P. Smith wrote: > 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?] > I use it in some of my code. If I want to cache some objects, I put them in a dict, using the id as the key. If I wanted to locate an object in a cache and didn't have id(), I'd have to do a linear search for it.
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