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.

On Fri, Oct 1, 2021 at 2:15 PM Ricky Teachey <ricky@teachey.org> wrote:
On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle <matthewgdv@gmail.com> wrote:
In the spirit of 3.9 allowing builtin collections like `list`, `dict`, `tuple`, and `set` to be subscripted for type-hinting to remove the need for importing their equivalents from `typing`, I'd like to propose the same thing for a few other builtin objects, namely:

`type` (for use instead of`typing.Type`)
`any` (for use  instead of `typing.Any`)
`callable` (for use instead of `typing.Callable`)

(I'm aware that a better syntax for type-hinting callables using arrow-syntax is potentially currently in the works, so maybe this last one can be ignored)

Having to explicitly import objects from `typing` for basic type-hinting use-cases is a not-inconsiderable source of frustration preventing their uptake, especially by beginners. 3.9 made a valuable step forward in reducing this friction, but I think we can go further.

 As was already stated: type[Thing] is already in the works, and callable is also being addressed elsewhere. This leaves any().

But any() is a function and not a type; it would have to graduate to a type for the type-hint syntax to work. Seems like that could cause some problems. Additionally, all() is in many ways the cousin of any(), and all() would presumably remain a function. I wonder if this asymmetry would also cause problems?

Have you thought about any of this?

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler