![](https://secure.gravatar.com/avatar/482f6832b98eccb86e2a5dc4de8aad91.jpg?s=120&d=mm&r=g)
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* ;)