[Python-Dev] Let's update CObject API so it is safe and regular!

[Guido van Rossum]

On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton <jim at 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/)