[Python-ideas] Conventions for Function Annotations

dag.odenhall at gmail.com dag.odenhall at gmail.com
Sun Aug 7 16:18:39 CEST 2011

On 7 August 2011 14:59, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
> What if you want to say that it raises both ValueError and ArithmeticError?
> Annotations never did support multiple annotations, it's a big
> drawback. This is a decorator though, you can do what you want. How
> about making __annotations__['raise'] a list?
> Otherwise sounds fine to me. The use of keywords in __annotations__ is
> pretty clever. :)

Neither does return support multiple values, and yet we can do "return x, y". :)

Annotations are bound to the evaluation of an expression and you're
free to put anything in them. I expect a convention of special-casing
tuples will emerge, especially as annotations are particularly
suitable for different sorts of "type hints" where tuples are already
used for issubclass/isinstance, in "except" clauses and for listing
base classes with type() etc.

I think annotations should be used sparingly: there's little need for
any sort of interoperability between multiple unrelated uses of
annotations. It would be rather complicated and unwieldy to say, both
put type hints and argument documentation strings in annotations.
Decorators are better suited for composability, as are docstrings for
documentation. If you're doing something like mapping a view function
to a template with the return annotation, it is unlikely that you need
to annotate it with type hints as well, for example.

More information about the Python-ideas mailing list