[Python-ideas] Conventions for Function Annotations

Guido van Rossum guido at python.org
Sun Aug 7 18:31:33 CEST 2011

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

Hi Dag,

Are you currently using annotations? Could you post some of the cool
usages that you are making of annotations? The explicit plan with
annotations (read PEP 3107) was that significant use should precede
the creation of conventions for use. So please don't wait until a
convention has been established -- go ahead and have fun with them,
and let us know what you are doing with them!

Re: declaring raised exceptions, IIUC Java is pretty much the only
language supporting such a feature, and even there the current view is
that they have not lived up to the expectation when the feature was
designed. So I would rather do nothing in that area.

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list