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 <pythonchb@gmail.com> 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 <ricky@teachey.org> wrote:
On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle <matthewgdv@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-leave@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/GJZFK3... 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-leave@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/FJJ4G2... Code of Conduct: http://python.org/psf/codeofconduct/