[Python-ideas] Conventions for function annotations

[Masklinn]

On 2012-12-03, at 18:27 , Guido van Rossum wrote:
> 
> Obviously this would require inventing and standardizing notations for
> things like "list of X", "tuple with items X, Y, Z", "either X or Y",
> and so on, as well as a standard way of combining annotations intended
> for different tools.

I've always felt that __getitem__ and __or__/__ror__ on type 1. looked
rather good and 2. looked similar to informal type specs and type specs
of other languages. Although that's the issue with annotations being
Python syntax: it requires changing stuff fairly deep into Python to
be able to experiment.

The most bothersome part is that I "feel" "either X or Y" (aka `X | Y`)
should be a set of type (and thus the same as {X, Y}[0]) but that doesn't
work with `isinstance` or `issubclass`. Likewise, `(a, b, c)` in an
annotation feels like it should mean the same as `tuple[a, b, c]` ("a
tuple with 3 items of types resp. a, b and c") but that's at odds with
the same type-checking functions.

The first could be fixable by relaxing slightly the constraints of 
isinstance and issubclass, but not so for the second.

[0] which works rather neatly for anonymous unions as `|` is the union
    of two sets, so the arithmetic would be `type | type -> typeset`,
    `type | typeset -> typeset` and `typeset | typeset -> typeset`,
    libraries could offer opaque types/typesets which would be composable
    without their users having to know whether they're type atoms or
    typesets