[Python-ideas] Type Hinting Kick-off

[Andrew Barnert]

On Dec 25, 2014, at 22:49, Eugene Toder <eltoder at gmail.com> wrote:

> The code of this kind comes up regularly in containers, like the ImmutableList
> above. Some standard types have methods likes this as well:
> 
> class Set(Generic[X]):
>    def union(self, other: Set[X]) -> Set[X]: ...

I'm not sure this problem exists.

The builtin set (and therefore the undocumented MyPy/typing TypeAlias Set) had a union method, but its signature is not that restrictive. It takes 1 or more arbitrary iterables of any element type, and of course it returns a set whose element type is the union of the element types of self and those. And the same is true in general for all of the builtin abstract and concrete types.

So, the fact that Guido's/Jukka's proposal doesn't make it easy to define types that are more restrictive than you'd normally want to use in Python doesn't seem to be a problem.

Sure, if you wanted to define more restricted C++/Swift/Haskell style collections for Python your want to be able to type them as easily as in those languages... But why do you want to define those collections?

The _opposite_ problem--that it's hard to define the _actual_ type of set.union or similarly highly parameterized types--may be more serious, but Guido acknowledged that one long ago, and I think he's right that it seems like the kind of thing that could be added later. (In the initial MyPy for 3.5 you can always define a one-argument version set[X].union(Iterable[Y])->set[Union[X, Y] and a generic multi-argument overload that, say, treats all the Iterable[Any] and returns Set[Any]. If we turn out to need parameter schemas for varargs in real programs, that can surely be added in 3.6 as easily as it could now. And hopefully it won't be needed. You need some kind of complete language to write such schemas in, and C++11 is a nice warning of what it looks like to try to do that declaratively in a non-declarative language.)