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

[Steven D'Aprano]

On Thu, Jan 17, 2019 at 04:48:38PM -0800, 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.

Indeed -- I've been told by one developer in no uncertain terms that 
using id() in this fashion is the only way to get the address of an 
object for use in ctypes. I don't know enough about ctypes to judge 
whether that is correct or not.

The sample code I've been shown is this:

    pointer_to_obj = id(obj)
    from_deref = ctypes.cast(pointer_to_obj, ctypes.py_object).value
    from_deref is obj  # True


> 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.

+1 to all of this.



-- 
Steve