<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 11, 2016 at 1:50 PM David Mertz <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> An equivalent way to write this in Python 2 is the following:<br>
><br>
>     def embezzle(self, account, funds=1000000, *fake_receipts):<br>
>         # type: (str, int, *str) -> None<br>
>         """Embezzle funds from account using fake receipts."""<br>
>         <code goes here><br>
<br>
</span>By using comments, the annotations would not be available at<br>
runtime via an .__annotations__ attribute and every tool would<br>
have to implement a parser for extracting them.<br>
<br>
Wouldn't it be better and more in line with standard Python<br>
syntax to use decorators to define them ?<br>
<br>
    @typehint("(str, int, *str) -> None")<br>
<span>    def embezzle(self, account, funds=1000000, *fake_receipts):<br>
</span><span>        """Embezzle funds from account using fake receipts."""<br>
        <code goes here><br></span></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I really like MAL's variation much better.  Being able to see .__annotations__ at runtime feels like an important feature that we'd give up with the purely comment style. </div></div></div></div></blockquote><div><br></div><div>I'd like people who demonstrate practical important production uses for having .__annotation__ information available at runtime to champion that. Both Google and Dropbox are looking at it as only being meaningful in the offline code analysis context. Even our (Google's) modified 2.7 with annotation grammar backported is just that, grammar only, no .__annotations__ or even validation of names while parsing. It may as well be a # type: comment. We explicitly chose not to use decorators due to their resource usage side effects.</div><div><br></div><div>2.7.x itself understandably is... highly unlikely to be modified... to put it lightly. So a backport of ignored annotation syntax is a non-starter there. In that sense I think the # type: comments are fine and are pretty much what I've been expecting to see. The only other alternative not yet mentioned would be to put the information in the docstring. But that has yet other side effects and challenges. So the comments make a lot of sense to recommend for Python 2 within the PEP.</div><div><br></div><div>.__annotations__ isn't something any Python 2 code has ever had in the past. It can continue to live without it. I do not believe we need to formally recommend a decorator and its implementation in the PEP. (read another way: I do not expect Guido to do that work... but anyone is free to propose it and see if anyone else wants to adopt it)</div><div><br></div><div>-gps</div><div><br></div></div></div>