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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
