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