Another concern I have is the over specification of types.
I have seen many examples of, e.g.
func(x: int, y: float, stuff: List(int]):
but very few of:
func(x: SupportsInt, y: SupportsFloat, stuff: Sequence[SupportsInt]):(or even Iterable[int])
Is that even the right thing to do to get generic number types? How do I specify a type that could be any number type (float, int, Fraction, Decimal, numpy.float32) ... I just spent a few minutes perusing the typing module and MyPy docs, and didn't find a discussion of that.
There is some discussion of the numeric tower in PEP 484 but the PEP says you should just use 'int', 'float' and be happy. *If* we were to change our mind on that we would let you spell it using numbers.Integer, numbers.Real etc., not SupportsInt, SupportsFloat. But the usability of any of those generic solutions is just terrible (too much typing for too little benefit) and honestly in many cases the runtime is not very good at these either (e.g. Decimal refuses to play). In practice it is just fiction that you can write your own numeric type.
Regarding Iterable[int] vs. Sequence[int], there are subtle semantic differences so it depends, but these have much better support and *are* encouraged. (What helps is that List is invariant but Sequence is covariant, and people often want covariance, so there is a real incentive to use Sequence, Iterable etc.)
But I'd really love to see the community as a whole start with more generic types in examples, and be clear that the concrete types should be used only when necessary -- even the typing module docs use a lot of concrete types in the examples.
Maybe you are speaking with a lot of enthusiasm but not a lot of experience? Generics aren't always better, and in many cases they just aren't worth the effort to get them right (just like not every bit of code you write needs to be published on PyPI).
I also have a feeling that most frameworks that use *runtime* introspection of types strongly prefer concrete types, i.e. list[int] rather than Sequence[T].
I think this is an issue for two reasons:
1) Folks learn from examples more than instruction -- people are very likely to follow the first example they see that seems to do the job.
It would be nice if someone did some work and collected a list of tutorials about type annotations that exist (especially the ones that are discoverable with a simple Bing query) and ranked them by quality.
2) as mentioned in this thread, library authors are being asked to type hint their libraries. I think it will be all too common for that type hinting to be more specific than required. For the most part, that won't cause any real issues right away, but as soon as someone uses that lib in a large project that enforces static type checking, it's could get ugly.
That's just the tip of the iceberg. In practice, there are quite a few reasons why the first few iterations of type hints for many popular packages fall short of expectations. Often the issue isn't just sufficiently wide types (like you speculate here) but missing types (for example, stubs containing functions with arguments but no annotations), missing methods/attributes, missing classes, and missing submodules. Not to mention signatures that are impossible to type with the current type system (you can't actually type zip() or filter(), for example).
We should definitely push back on zealous new converts to typing who insist that everything should be annotated. But we should also recognize that even in their current, far from perfect state, type annotations can provide a lot of value, when used right. (Have you run into VS Code yet? It gets tremendous value from typing stubs, in the form of improved auto-complete and hover-doc functionality.)