[Python-Dev] PEP 318 (was re: redefining is)

[Phillip J. Eby]

At 09:02 PM 3/24/04 -0500, Bob Ippolito wrote:

>it could also be simply:
>
>class foo [provides(Immutability)]:
>     pass
>
>or...
>
>declareImplements(int, instancesImplement=(Immutability,))
>
>Basically what you want, when you are declaring type information, is a way 
>to find the type information.  You don't really know nor care if it's 
>actually part of the type object.  It's actually better that it's not, 
>such as when you are declaring stuff about types that you can't change -- 
>like int, long, etc.  It just so happens that PyProtocols (or something 
>like it, but I demonstrate PyProtocols syntax) already takes care of this 
>for you.

Technically, if/when PyProtocols supports decorators, it'll probably be 
spelled:

     class foo [
         protocols.instances_provide(Immutability)
     ]:
         ...

or maybe:

     class foo [
         protocols.implements(Immutability)
     ]:
         ...

to distinguish from the class *itself* providing immutability.  I've been 
trying to promote a Python-wide terminology that distinguishes between 
"providing X" (being an object that does X), "supporting X" (either 
providing X or being adaptable to X), and "implementing X" (being a type 
whose instances provide X).  Zope X3 and PyProtocols both conform to this 
terminology in their APIs, at least with respect to provides vs. implements.

I do see a use for a 'provides()' decorator, though, in relation to 
functions.  E.g.:

def something(x,y) [protocols.provides(ICallableWithTwoArgs)]:
     ...

Too bad there's no way to do this with modules, which are the only 
remaining thing PyProtocols uses stack inspection to annotate.  But I can't 
even begin to guess how one would create a module decorator syntax.  :)