On Fri, Oct 1, 2021 at 2:52 PM Christopher Barker <python...@gmail.com> wrote:
> On Fri, Oct 1, 2021 at 8:05 AM Paul Moore <p.f.mo...@gmail.com> wrote: > >> Having to take the runtime cost of an import to do a development-time >> static analysis of the code, sort of is, though... > > > Perhaps so — though I’d think that could be addressed in a more > comprehensive way. Thus can’t be the only runtime overhead that could > conceivably be avoided. > > And if that was the primary goal, add Any to builtins… > > -CHB > > >> >> Paul > > on the one hand: with all the other type-hint syntax made available (gone are the need for importing Optional, Union, Type, Dict, List, Tuple, and Set) and more coming, having to import Any certainly does feel annoying. it seems to me, in my own code at least, that many others in the typing module are used just as often (if not more!) than Any: TypeVar, Generic, and ClassVar to name a few. there are also the collections.abc types. input argument hints are more robust and proper when using types like : Mapping[] and Sequence[] (and their Mutable friends) rather than using Dict[] and List[] and Tuple[] (which can now be dict[] and list[] and tuple[]). so these are in constant use for function argument type-hints. so if Any is going to matriculate its way into built-ins, i don't see much of a reason why a big chunk of the rest of the typing module shouldn't. that being the case, i think it should probably stay where it is. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XO33WHAD3JYXF4A6BXX5AK2UKTWEKN2G/ Code of Conduct: http://python.org/psf/codeofconduct/
