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