I totally do not understand the requirement for the dictionary and its extra overhead.<br><br><div><span class="gmail_quote">On 8/15/06, <b class="gmail_sendername">Collin Winter</b> <<a href="mailto:collinw@gmail.com">
collinw@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>@typechecker<br>def foo(a: {'type': Number},<br> b: {'type': Number}) -> {'type': Number}
<br><br><br>I'm going to raise the bar for future ideas on this subject: any<br>proposals must be able to address the following use cases:<br><br>1) Static analysis tools (pychecker, optimising compilers, etc) must<br>be able to use the annotations
<br>2) Decorator-based annotation consumers must be able to use the annotations<br>3) Non-decorator-based annotation consumers (pydoc, etc) must be able<br>to use the annotations</blockquote><div><br>Consider the following syntax:
<br><br>class MyType:<br> def __init__(self, name):<br> <a href="http://self.name">self.name</a> = name<br><br>Number = MyType("Number")<br>Tuple = MyTime("Tuple")<br><br>def foo(a: tc(Number)) -> Tuple(Number, Number)
<br></div><br>1. Static analysis tools can deal with this as much as with ANY truly Pythonic syntax. Their ability to deal will depend (as in any syntax) on their ability to do module or whole-program analysis. In your syntax, or mine, "Number" could be defined dynamically. In either case, someone could say "Number = None" and confuse everything.
<br><br>2. A decorator based anaysis could look at __signatures__ and do what it needs.<br><br>3. Similarly for non-decorator analyzers.<br><br>In fact, given that decorators are just syntactic sugar for function calls, I don't see why they should require special consideration at all. If the syntax works well for non-decorator consumers then decorators will be just a special case. As far as static analysis tools: Python has never made major concessions to them. Minor concessions, yes.
<br><br>I'd ask that you add the following requirement:<br><br> * must define how multiple annotation syntaxes can assign potentially differing meanings to built-in types and objects, on the same parameter, without actually conflicting
<br><br>My full program (meeting all requirements) follows.<br><br> Paul Prescod<br><br>====<br><br>def simulate_signature(sig):<br> "simulates the signature feature of Pythn 3000"<br> def _(func):<br> func.__signature__ = sig
<br> return func<br> return _<br><br>def my_print_signature(func):<br> "a demo decorator that prints signatures."<br> if hasattr(func, "__signature__"):<br> sig = func.__signature__
<br> [my_print_arg(name, value) for name, value in sig.items()]<br> return func<br><br>def my_print_arg(name, annotation):<br> """print a single argument's <br> declaration, skipping unknown anno types."""
<br> if isinstance(annotation, list):<br> [my_print_arg(name, anno) <br> for anno in annotation]<br> elif conformsToInterface(annotation, MyType):<br> print name<br> annotation.print_arg
()<br><br>def conformsToInterface(object, interface):<br> "naive implemenation of interfaces"<br> return isinstance(object, interface)<br><br>class MyType:<br> def __init__(self, *children):<br> self.children
= children<br> def print_arg(self):<br> print self.children<br><br>#defined in your module. I have no knowledge of it<br>class YourType:<br> def __init__(self, *stuff):<br> pass<br><br># a simple signature
<br><br># real syntax should be:<br># def foo(bar: MyType(int))<br>@simulate_signature({"bar": MyType(int)})<br>def foo(bar):<br> return (bar, bar)<br><br># use print signature decorator<br><br># real syntax should be:
<br>
# def foo2(bar: [MyType(int)...]) -> [MyType(...]<br>
@my_print_signature<br>@simulate_signature({"bar": [MyType(int), YourType("int")], <br> "return": [MyType(tuple([int, int])),<br> YourType("tuple of int,int")]})
<br>def foo2(bar):<br> return (bar, bar)<br><br># can also be used as non-decorator<br>for name, val in vars().items():<br> my_print_signature(val)<br><br></div>