On 8/15/06, <b class="gmail_sendername">Collin Winter</b> <<a href="mailto:collinw@gmail.com">collinw@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So basically what you're saying is that there would be a more-or-less<br>standard wrapper for each application of function annotations. </blockquote><div><br>No, I explicitly said that there may or may not arise standards
based upon the existence or non-existence of community consensus and
convergence of requirements. Just as there may or may not arise a standard Python web application framework depending on whether the community converges or does not.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How is<br>this significantly better than my dict-based approach, which uses<br>standardised dict keys to indicate the kind of metadata?</blockquote><div><br>The dict-based approach introduces an extra namespace to manage. What if two different groups start fighting over the keyword "type" or "doc" or "lock"? Python already has a module system that allows you to use the word "type" and me to use the word "type" without conflict (though I can't guarantee that it won't be confusing!). Python's module system allows renaming and abbreviating: both valuable features.
<br><br>Also, the dict-based approach is just more punctuation to type. What is the dict equivalent for:<br><br>def foo(a: type(int)) -> type(int):<br> ...<br><br>versus<br><br>def foo(a: {"type":int}) -> {"type": int}:
<br><br>In my approach you could do this:<br><br>Int = type(int)<br><br>def foo(a: Int) -> Int<br><br> Paul Prescod<br></div></div>