Re: PEP 3107 Function Annotations for review and comment

BJörn Lindqvist wrote:

On 12/29/06, Tony Lownds <tony@xxxxxxxxxxx> 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
.

Relevant Pages

  • Re: PEP 3107 Function Annotations for review and comment
    ... using decorators and doc strings. ... popular in the Python community. ... self-evident what purpose function annotations would serve. ... I also wonder why a very obtrusive syntax addition is needed when it ...
    (comp.lang.python)
  • Python evolution: Unease
    ... or syntax bickering; call it enforced pragmatism. ... why I've liked Python: it's elegant and simple and still dynamic and ... You could do worse for a clean and pragmatic language. ... a better standard ide, an integrated db interface with a proper ...
    (comp.lang.python)
  • Re: Herbert Schildt, author of The Complete C++ Reference (NOT C Unleashed) rehabilitated on wikiped
    ... well as on Amazon and wikipedia, on Schildt, Heathfield et al. did try ... Annotated Annotated C Standard" at http://www.lysator.liu.se/c/schildt.html, ... auditing EACH AND EVERY LINE for character width dependent operations ... standard (something that is not mentioned in the annotations), ...
    (comp.programming)
  • The annotated annotated annotated C standard
    ... Here I shall start a review of "The Annotated Annotated C Standard" at ... show an orientation towards the needs of the working C programmer ... auditing EACH AND EVERY LINE for character width dependent operations ... standard (something that is not mentioned in the annotations), ...
    (comp.programming)
  • Re: Is a "real" C-Python possible?
    ... Python 3 will have optional 'type' annotations, ... Since a possible compiler ... I'm yet not sure about type systems for typed snapshots ...
    (comp.lang.python)