[Python-ideas] Proposal to extend PEP 484 (gradual typing) to support Python 2.7

[Gregory P. Smith]

On Mon, Jan 11, 2016 at 1:50 PM David Mertz <mertz at gnosis.cx> wrote:

> > An equivalent way to write this in Python 2 is the following:
>> >
>> >     def embezzle(self, account, funds=1000000, *fake_receipts):
>> >         # type: (str, int, *str) -> None
>> >         """Embezzle funds from account using fake receipts."""
>> >         <code goes here>
>>
>> By using comments, the annotations would not be available at
>> runtime via an .__annotations__ attribute and every tool would
>> have to implement a parser for extracting them.
>>
>> Wouldn't it be better and more in line with standard Python
>> syntax to use decorators to define them ?
>>
>>     @typehint("(str, int, *str) -> None")
>>     def embezzle(self, account, funds=1000000, *fake_receipts):
>>         """Embezzle funds from account using fake receipts."""
>>         <code goes here>
>>
>
> 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.
>

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.

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.

.__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)

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160111/180b42db/attachment.html>