Is there a reason we can't use "Object" and make "Any" just an alias for "Object"?
On Fri, Oct 1, 2021, 10:47 Christopher Barker <[email protected]> wrote: > > > 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 <[email protected]> wrote: > >> On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle <[email protected]> >> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/FJJ4G2ZHDTZS7ETVCXYXWRNQ3GAHK2BL/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YX5F2SOYTFQ54FDXSEUBU2MWFGOIJHDA/ Code of Conduct: http://python.org/psf/codeofconduct/
