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/SFR23A2OCQKAKTIDUGOMMRPMAMNJO66Z/ Code of Conduct: http://python.org/psf/codeofconduct/
