n Thu, Jan 17, 2019 at 4:51 PM Gregory P. Smith <greg at krypto.org> 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. IME it's reasonably common with ctypes, for cases where you need to do some gross hack and there's no other option. Here's an example in jinja2: https://github.com/pallets/jinja/blob/9fe9520f2daa1df6079b188adba758d6e03d6af2/jinja2/debug.py#L350 I haven't seen it with cffi or cython. (cffi explicitly doesn't provide any way to access the CPython C API, and in cython you can just cast an object to a pointer.) > 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. Using id() like this is certainly offensive to our sensibilities, but in practice I don't see how it causes much harm. If you are doing *anything* with PyObject*, then you're tying yourself to implementation details of CPython (and usually a specific version of CPython). That's not great, but at that point relying on CPython's implementation of id() is the least of your worries, and it tends to be a self-correcting problem. -n -- Nathaniel J. Smith -- https://vorpus.org
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