[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", \

    /* This macro would be used if PyCObject_ImportEx() was created.
    #define PyDateTime_IMPORT \
            PyDateTimeAPI = (PyDateTime_CAPI*)
    PyCObject_ImportEx("datetime", \
    "datetime_CAPI", \

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

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