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. :)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4