PEP 3107 Function Annotations for review and comment

[Diez B. Roggisch]

BJörn Lindqvist wrote:

> On 12/29/06, Tony Lownds <tony at pagedna.com> wrote:
>> Rationale
>> =========
>>
>> Because Python's 2.x series lacks a standard way of annotating a
>> function's parameters and return values (e.g., with information about
>> what type a function's return value should be), a variety of tools
>> and libraries have appeared to fill this gap [#tailexamp]_.  Some
>> utilise the decorators introduced in "PEP 318", while others parse a
>> function's docstring, looking for annotations there.
>>
>> This PEP aims to provide a single, standard way of specifying this
>> information, reducing the confusion caused by the wide variation in
>> mechanism and syntax that has existed until this point.
> 
> I think this rationale is very lacking and to weak for such a big
> change to Python. I definitely like to see it expanded.
> 
> The reference links to two small libraries implementing type checking
> using decorators and doc strings. None of which to seem to be very
> popular in the Python community. Surely, those two libraries *alone*
> can't be enough of a motivation for this? To me, it is far from
> self-evident what purpose function annotations would serve.
> 
> I also wonder why a very obtrusive syntax addition is needed when it
> clearly is possible to annotate functions in today's Python. Why is
> syntax better than just adding a function annotation decorator to the
> standard library?
> 
>     @annotate(a = int, b = dict, c = int)
>     def foo(a, b, c = 5):
>         ...
> 
> Are decorators to ugly?

I prefer the proposed syntax - it is much more concise and. modeled after
well-known declaration syntaxes in other languages. Additionally, it spares
us the doubled parameter list as your example above - and that is important
here I'd say.

Typing is a difficult and controversial subject. However, sooner or later
python will grow JIT-compilers that will take advantage of such
declarations, and I think it is better to have one accepted way of doing it
hardwired than several concurring self-baked implementations.

Diez