[Python-ideas] Conventions for Function Annotations

[dag.odenhall at gmail.com]

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

I'm toying with them for adaptation, interfaces and dependency
injection from a component registry. Each use is about type constants,
but not necessarily in the vein of static type checking, which I think
stands to show their strengths and "Pythonicity".

I do kinda think there's some need of informal conventions,
examplified by Mathias post: his decorator sets the 'raises' key,
effectively making "raises" a reserved keyword in function arguments
using the decorator!


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

Probably true, though probably in part because it isn't optional in
Java. In Pythonland it's probably more useful to make i part of the
documentation á la the :raises: field of Sphinx. Much of the benefits
of exceptions are that they can be ... unexpected, and bubble up:
doing something like reraising unexpected exceptions as a TypeError
would not likely be very useful (well, maybe a little useful with the
new __cause__/__context__) and neither do exceptions fit in well with
my other uses (adaptation, dependency injection) of annotations.

Some convention for annotating 'yield' may still be useful though,
although one alternative convention could use some form of
"parametrized types" and the return annotation: foo() ->
Iterator[tuple]. Now we just need to add this to ABCMeta. *cough* ;)