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 <ri...@teachey.org> wrote:
> On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle <matthew...@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
>
>
>
>
_______________________________________________
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/OGQFWDWV7MOMWSRKNSYVJFABMIIPV6WX/
Code of Conduct: http://python.org/psf/codeofconduct/
