On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton <j...@zope.com> wrote: > The original use case for CObjects was to export an API from a module, in > which case, you'd be importing the API from the module.
I consider this the *only* use case. What other use cases are there? > The presence in the > module indicates the type. Of course, this doesn't account for someone > intentionally replacing the module's CObject with a fake. And that's the problem. I would like the following to hold: given a finite number of extension modules that I trust to be safe (i.e. excluding ctypes!), pure Python code should not be able to cause any of their CObjects to be passed off for another. Putting an identity string in the CObject and checking that string in PyCObject_Import() solves this. Adding actual information about what the CObject *means* is emphatically out of scope. Once a CObject is identified as having the correct module and name, I am okay with trusting it, because Python code has no way to create CObjects. I have to trust the extension that exports the CObject anyway, since after all it is C code that could do anything at all. But I need to be able to trust that the app cannot swap CObjects. >> Attaching some kind of type info to a CObject and having >> an easy way of checking it makes sense to me. If the >> existing CObject API can't be changed, maybe a new >> enhanced one could be added. > > I don't think backward compatibility needs to be a consideration for Python > 3 at this point. I don't see much advantage in the proposal, but I can live > with it for Python 3. Good. Let's solve this for 3.1, and figure out whether or how to backport later, since for 2.6 (and probably 2.7) binary backwards compatibility is most important. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
