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