[Python-ideas] Conventions for Function Annotations

[Devin Jeanpierre]

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

That's neither here nor there. That is a single return value, a tuple.
Not different kinds of return values, such as returning something that
might be annotated as a "sequence" as well as, in other circumstances,
returning something that might be annotated as a "dict".

Since few to no sanely written functions return incompatible types,
there isn't as much reason to complain about this.

On the other hand, almost every single function in the stdlib can
raise multiple different exceptions. A "raises" annotation is not very
useful unless you can annotate multiple exceptions that may be raised.

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

The decorator you have provided is _not_ composable. In fact, that was
my complaint. I never said anything about docstrings or mixing and
matching annotations.

Devin

On Sun, Aug 7, 2011 at 10:18 AM, dag.odenhall at gmail.com
<dag.odenhall at gmail.com> wrote:
> 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.
>