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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4