[Python-Dev] Let's update CObject API so it is safe and regular!
Larry Hastings
larry at hastings.org
Thu Apr 2 01:26:15 CEST 2009
Jim Fulton wrote:
> The only type-safety mechanism for a CObject is it's identity. If you
> want to make sure you're using the foomodule api, make sure the
> address of the CObject is the same as the address of the api object
> exported by the module.
That doesn't help. Here's a program that crashes the interpreter,
something I shouldn't be able to do from pure Python:
import _socket
import cStringIO
cStringIO.cStringIO_CAPI = _socket.CAPI
import cPickle
s = cPickle.dumps([1, 2, 3])
How can cPickle determine that cStringIO.cStringIO_CAPI is legitimate?
> That would break backward compatibility. Are you proposing this for
> Python 3?
I'm proposing this for Python 3.1. My understanding is that breaking
backwards compatibility is still on the table, which is why I wrote the
patch the way I did. If we have to preserve the existing API, I still
think we should add new APIs and deprecate the old ones.
It's worth noting that there's been demand for this for a long time.
Check out this comment from Include/datetime.h:
#define PyDateTime_IMPORT \
PyDateTimeAPI = (PyDateTime_CAPI*)
PyCObject_Import("datetime", \
"datetime_CAPI")
/* This macro would be used if PyCObject_ImportEx() was created.
#define PyDateTime_IMPORT \
PyDateTimeAPI = (PyDateTime_CAPI*)
PyCObject_ImportEx("datetime", \
"datetime_CAPI", \
DATETIME_API_MAGIC)
*/
That was checked in by Tim Peters on 2004-06-20, r36214. (At least, in
the py3k/trunk branch; I'd hope it would be the same revision number in
other branches.)
/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090401/e118e00b/attachment.htm>
More information about the Python-Dev
mailing list