(original) (raw)

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/