[Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

[Nathaniel Smith]

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