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

[Jim Fulton]

On Apr 2, 2009, at 7:28 AM, Greg Ewing wrote:

> 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.
>
> I don't follow that. If you already have the address of the
> thing you want to use, you don't need a CObject.

I was refering to the identity of the CObject itself.

>> 2. Only code provided by the module provider should be accessing  
>> the  CObject exported by the module.
>
> Not following that either. Without attaching some kind of
> metadata to a CObject, I don't see how you can know whether
> a CObject passed to you from Python code is one that you
> created yourself, or by some other unrelated piece of
> code.

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.  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.

> 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.

Jim

--
Jim Fulton
Zope Corporation