
On Tue, Nov 30, 2021 at 3:31 PM Guido van Rossum <guido@python.org> wrote:
There is some discussion of the numeric tower in PEP 484 but the PEP says you should just use 'int', 'float' and be happy.
Thanks -- I didn't think to look there. And this: "when an argument is annotated as having type float, an argument of type int is acceptable" makes it pretty workable. I do wonder what happens with oddball numbers, like, say numpy.float32. But maybe that's Ok, as for though most part one will be dealing with arrays of them -- the scalars are fairly rare in real code. however, IIRC, __index__ was introduced at least partially so that numpy integer types could be used as indexes. Which would mean SupportsIndex for a type that's going to be used as an index, yes?
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.
Yes, Decimal and Fraction are pretty special purpose, really.
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?
well, yes, for sure.
Generics aren't always better, and in many cases they just aren't worth the effort to get them right
I suspect that depends a bit on the use case. For something internal to one system, probably not worth the effort at all. But for a general purpose library, I'm (perhaps needlessly) concerned about types getting locked down more than they need to be, just because its easier, and "it works for me"
(just like not every bit of code you write needs to be published on PyPI).
Someone should tell that to all the folks publishing 0.0.0.1 version of packages :-)
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].
This is getting into what it means to use Types at runtime -- if it's runtime type checking, then more abstract types might be fine. But if it's using the type itself (like my use case), then absolutely -- my system will only work with real concrete type objects. Though that may not play that well with type checkers :-(
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.
yes, it would.
We should definitely push back on zealous new converts to typing who insist that everything should be annotated.
well, we got folks wanting to change PEP 8 becuase they don't want their linter to complain -- so it will be a battle.
(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.)
Some of the folks on my team use it -- I've been meaning to check it out -- one more reason now. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython