[Python-ideas] Improving the expressivity of function annotations

Masklinn masklinn at masklinn.net
Tue Apr 5 08:35:18 CEST 2011


On 2011-04-05, at 02:44 , Carl M. Johnson wrote:
> On Mon, Apr 4, 2011 at 9:03 AM, Masklinn <masklinn at masklinn.net> wrote:
>> Again, the issue is function annotations, which was my context. The example was just to give an idea of the operation performed. In function annotations, unless you went with type parameters and ``tuple[A, B, C]``, ``(A, B, C)`` would likely be interpreted as "a triple of instances of types A, B and C".
> 
> Yes, but since function annotation don't do anything at present (and
> maybe never will by default), your function will have to use a
> decorator to turn on the type checking. At that point, it's just a
> matter of API design how best to do it. For example, let's say I have
> a sum function, and I want it to take an iterator containing some type
> and then return something of the same type. In semi-C-ish style, we'd
> call this list[int] -> int or list[Generic number] -> Generic number.
> But since we're making up our own API for type checking, in this case
> we can make it work however we want. We don't need to have a
> particular grammar baked into the language.
I would still think that, for the usage of function annotation to take off (and be used by multiple tools), there needs to be some kind of commonality between all tools. At least for the features closest to core.

Indeed, function annotations do currently provide a common (very bare) starting point which was found good enough (at least as an experiment) to replace/supersede/complement the thousand of possible docstring styles of function annotations (from annotations-like to Sphinx info-fields through doxygen, epydoc and dozens of ad-hoc schemes).

The root of my proposal is that, after using both statically typed and dynamically typed languages and writing a bunch of API docs (mostly for Python and Javascript), I don't think the current function annotations provide enough ground for language users to stand on, be it as documentation or as meta-information for static checking tools.


More information about the Python-ideas mailing list