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

Phillip J. Eby pje at telecommunity.com
Wed Mar 24 21:32:56 EST 2004

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

More information about the Python-Dev mailing list