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@gmail.com <dag.odenhall@gmail.com> wrote:
On 7 August 2011 14:59, Devin Jeanpierre <jeanpierreda@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.