The fact that the built in “any” is not a type is not an implementation detail. any() and typing.Any are completely different things/concepts. They just happen to be spelled the same.
I don’t think it’s a bad thing that objects that are specifically about Type Hinting can be found in the typing module. Overloading names in builtins to save an import is a really bad idea. -CHB On Fri, Oct 1, 2021 at 7:10 AM Ricky Teachey <ri...@teachey.org> wrote: > On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle <matthew...@gmail.com> > wrote: > >> I had no idea that type[Something] was already a thing, and this makes me >> so happy! :) >> >> It's true that `any` would have to converted to be either: >> >> 1) an object implementing __call__ and __getitem__ >> 2) a type implementing __new__ and __class_getitem__ >> 3) some special-cased type implemented in the interpreter that couldn't >> be recreated in python (like maybe implementing `any` as a special subclass >> of `builtin_function_or_method` that can be subscripted or allowing >> `builtin_function_or_method` to be optionally subscriptable) >> 4) some other option I'm not thinking of? >> >> The first two options would *technically* represent a >> backwards-incompatible change, but it's hard to imagine any **sane** code >> that would be affected. You'd have to be doing something like: >> >> ``` >> import builtins >> >> builtin_function_or_method = type(max) >> >> for item in builtins.__dict__.values(): >> if isinstance(item, builtin_function_or_method): >> ... # do something with all the builtin functions, which would >> no longer include `any` >> ``` >> >> The third option would neatly sidestep this and be fully >> backwards-compatible, but I assume would represent a bigger change to the >> interpreter. >> >> As I don't have any knowledge of the interpreter's internals I can't >> really give a preference for an approach, but I think the first step would >> be agreeing that a subscriptable version of `any` for type-hinting is >> desirable. >> >> If this seems to be something that people want then I'm sure there are >> people far more qualified than me to discuss implementation details. If not >> then it's irrelevant anyway. >> >> > I'd expect to see something more like an EAFP construct; > > try: > maybe_all_maybe_mapping[key] > except KeyError: > # it's all()! > > I agree it would be weird. But not hard to imagine. > > --- > 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/GJZFK3VBIXFYAGYJSQVPFMRRGOK7B3NK/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/FJJ4G2ZHDTZS7ETVCXYXWRNQ3GAHK2BL/ Code of Conduct: http://python.org/psf/codeofconduct/
