[Python-ideas] Conventions for Function Annotations

[Devin Jeanpierre]

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

Devin

On Sun, Aug 7, 2011 at 7:27 AM, dag.odenhall at gmail.com
<dag.odenhall at gmail.com> wrote:
> This isn't really a proposal for any sort of language/stdlib change,
> rather I felt like discussing the potential for informal standard
> conventions with annotations.
>
> Probably for the better, there is no special syntax for annotating
> raised exceptions or yields from a generator. In line with how the
> "->" syntax sets the 'return' key, I suggest an informal standard of
> representing keywords this way, for example in a decorator for
> raise/yield annotations:
>
> # third-party decorator
> @raises(ValueError)
> def foo():pass
>
> assert foo.__annotations__['raise'] == ValueError
>
> This might be an obvious solution, but I just wanted to "put it out
> there" up front, before inconsistent workarounds emerge. This
> convention should work because it is primarily needed for control
> structures that are reserved keywords anyway. The one exception I can
> think of is the inverse of yield: generator.send() - "send" could
> conflict with a function argument, and should therefore not be put in
> __annotations__. (A hack could be to use a different but semantically
> related keyword like 'import', or an otherwise invalid identifier like
> 'send()', but it might be best to simply not use __annotations__ for
> this.)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>