[Zope3-dev] Re: Interface support in Python? (was Re: [Zope3-dev]
Proposal: Improving on __implements__)
Phillip J. Eby
pje@telecommunity.com
Wed, 22 Jan 2003 15:59:13 -0500
At 02:04 PM 1/22/03 -0500, Jim Fulton wrote:
>I think now would be a good time to make a new Python interfaces
>PEP. Such a PEP should probably be a combination interface
>and adapter PEP. I'd be willing to work on this, but not alone.
>Are other folks intereseted in working on this?
I'm more than willing to help criticize it. ;)
Seriously, though, is there any indication that the BDFL would support such
a thing? Would Guido perhaps be willing to state what preconditions an
interface PEP would require to meet with his approval?
If I understand correctly, and I probably don't, his main issues have to do
with the inheritance of "implementedness", to coin a phrase. I think a PEP
would need to have a way for you to spell that:
1. something doesn't support a particular interface or interfaces supported
by its base classes, or...
2. something doesn't support any interfaces supported by its base classes,
only what it explicitly defines.
I think for me, another issue would most definitely be proper support for
metaclasses, i.e. spelling the difference between what classes and
instances implement. While it may be true that "most people" will not
implement metaclasses, it is still quite possible for them to be bitten by
the difference when using metaclasses provided by someone
else. (Currently, __class_implements__ works reasonably well, but it can
get really hairy when you have metametaclasses in play.)
If we were writing the interface package today -- assuming Python 2.2 and
up -- I'd suggest always asking an object's class for what it implements,
passing in either the instance or the class. That seems to be the only way
to be completely unambiguous as to whose interfaces you're asking for, when
the object in question might itself be a class or type. An __implements__
descriptor can only be unambiguous if it's defined on the meta-most
metaclass of the system. So to do it cleanly it'd have to be part of type
'type', which implies a language change.
Offhand, this sounds like something with no chance of getting in 2.3, and
therefore unable to significantly affect Zope 3, but maybe I'm missing
something here.