[Python-Dev] PEP 318 (was re: redefining is)
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