On Tue, Nov 30, 2021 at 3:31 PM Guido van Rossum <gu...@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
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PTZBYWYU66JVOWVHKISKDBMQZDLWEK43/ Code of Conduct: http://python.org/psf/codeofconduct/
