This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Make builtins.callable "generic"
Type: enhancement Stage: patch review
Components: Versions: Python 3.10
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, gvanrossum, hauntsaninja, kj, levkivskyi, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2020-10-20 21:48 by hauntsaninja, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 22848 closed hauntsaninja, 2020-10-21 06:22
Messages (15)
msg379169 - (view) Author: Shantanu (hauntsaninja) * Date: 2020-10-20 21:48
In the post PEP 585 world, it seems like a bit of a stumbling block for builtins.callable to not able to be parametrised (in a runtime context). Post PEP 604, I'd expect typing.Callable to be the most used typing import after typing.Any, so much of PEP 585's rationale should apply to this case too.

Concretely, one way to implement this would be to turn callable into a type whose __new__ returns a bool and which implements __class_getitem__. We could throw in an __instancecheck__ so that `isinstance(x, callable) == callable(x)`.

PS: Despite being code that crashes instantly, I was still able to find some instances of `isinstance(x, callable)` on popular Github projects:
msg379179 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2020-10-21 01:48
+1 to this. I'm more surprised that callable wasn't already able to do that (also surprised at the ``isinstance(x, callable)`` code crashing). 

I think the implementation would be slightly different than what you proposed. I'd like to give it a shot if you aren't already doing this, and if there's more support for this too.
msg379182 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-10-21 02:24
I'm not against this, though I'm not sure it really buys us much (Any still has to be imported from typing). Maybe you can submit a PR? Running the tests might be informative.
msg379196 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-21 06:32
Callable is very special generic. It differs in many ways from List or Awaitable. You cannot just use GenericAlias.

Also, in contrary to list() or dict(), callable() is not a constructor, it is a predicate. callable[[int], str]() does not make sense.
msg379197 - (view) Author: Shantanu (hauntsaninja) * Date: 2020-10-21 06:53
Sure, I put together a draft PR here: Tests pass cleanly, though timeit indicates callable is slower.

I haven't added instancecheck, which we should consider doing, since `isinstance(x, callable)` would now return False, instead of raising TypeError.

I hack around that using `callable.__new__`, so `callable[[int], str]()` raises a TypeError in my draft PR. Note that `callable[[int], str](f)` would work the same as `callable(f)` does today (which from a typechecking perspective is similar to the fact that `list[int](("a", "b", "c"))` works).
I agree that callable being a predicate means that there probably isn't an aesthetically pleasing way of doing this.

I'm a little out of my comfort zone, so please let me know if you see a better way of doing things :-)
msg381072 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-16 05:29
I'd like to pursue this for real; other issues for callable have popped up, and ( is also related but already fixed).

From 42195 I learn that __args__ ought to be hashable. I would prefer it to still be structured, e.g. callable[[int, str], float].__args__ should be ((int, str), float).

This means we have to change typing.Callable and as well (the latter may share code with builtins.callable, but typing.Callable should probably stay separate, but returning the same structure).
msg381080 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-11-16 08:38
Sorry, but making builtins.callable generic looks wrong to me. It is a predicate, not a constructor. If it would be called "iscallable" instead of "callable" nobody would propose to make it generic, right? It's just a coincidence that the name of this predicate equals to the name of typing.Callable and

builtins.callable was removed in Python 3.0 in favor of instance check for collections.Callable. Maybe removing it again (or renaming to iscallable) would solve confusion?
msg381081 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-11-16 09:25
> Sorry, but making builtins.callable generic looks wrong to me. It is a predicate, not a constructor. If it would be called "iscallable" instead of "callable" nobody would propose to make it generic, right? It's just a coincidence that the name of this predicate equals to the name of typing.Callable and

I concur with Serhiy on this.
msg381141 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-16 18:48
Well, it's certainly no bug fix, but just as PEP 585 lets us write list[int] instead of typing.List[int], it could be considered useful to be able to write callable[[int, int], str] instead of typing.Callable[[int, int], str].

It's easy enough to make it work so that callable(x) returns a bool but callable[X, Y] returns a built-in subclass of types.GenericAlias (the built-in type).

That said, I don't have data about how popular Callable is compared to other types (Sequence/Iterable etc. which will remain in Maybe someone can do some grepping of popular projects?
msg381151 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-11-16 20:24
From implementation perspective it is not easy at all. You will need to create a special class with methods __call__ and __getitem__ (and several other methods and attributes, like __repr__, __reduce__, __name__, __doc__, __module__, __text_signature__, etc) and make builtins.callable an instance instead of just built-in function. It can also affect performance of callable().
msg381155 - (view) Author: Shantanu (hauntsaninja) * Date: 2020-11-16 20:45
My implementation in PR 22848 turns callable into a type and uses `__new__`. It isn't too bad. It does appear to affect performance of callable though.

Here's some data on how often typing imports are used. This is the number of files in which `from typing import X` is present in mypy_primer's corpus (searched using the AST). My read of this is that Callable is meaningfully more used than anything else in
'Optional': 2563
'Any': 2402
'List': 2383
'Dict': 2150
'Tuple': 1592
'Union': 1269
'Callable': 1058
'Iterable': 609
'Set': 580
'cast': 505
'Sequence': 465
'Type': 438
'Iterator': 385
'TypeVar': 302
'Mapping': 301
'Generator': 194
'NamedTuple': 138
'Text': 127
'IO': 120
'Awaitable': 116
msg381158 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-11-16 21:14
We specially introduced __mro_entries__ to make types in the typing module not classes. Turning builtins.callable into a class is a step back.
msg381641 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-23 05:21
Hm. Shantanu's list shows that the next thing we should make usable without importing typing is Any. (I haven't any idea how to do that other than just making it a builtin.) But after that we should definitely tackle Callable, and the obvious way to do it is to make callable indexable. But does that mean it has to be a type? I don't think so -- it just has to be an object whose class defines both __call__ and __getitem__. Pseudo code:

class callable:
    def __call__(self, thing):
        return hasattr(thing, "__call__")
    def __getitem__(self, index):
        # returns a types.GenericAlias instance
        # (or a subclass thereof)

I honestly don't think that we should support isinstance(x, callable) even if some people think that that should work.

In any case, we should first answer the questions that are still open for issue 42195 -- what should __args__ for [cC]allable[[int, int], str] be? (int, int, str) or ((int, int), str) or ([int, int], str) or (Tuple[int, int], str) are all still on the table. Please refer to that issue.
msg381657 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-11-23 09:20
Could not object replace Any?
msg381671 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2020-11-23 15:19
No, they both have a different meaning. Object has (almost) no attributes. Any has all attributes.
Date User Action Args
2022-04-11 14:59:37adminsetgithub: 86268
2020-11-23 15:19:16gvanrossumsetmessages: + msg381671
2020-11-23 09:20:56serhiy.storchakasetmessages: + msg381657
2020-11-23 05:21:48gvanrossumsetmessages: + msg381641
2020-11-16 21:14:50serhiy.storchakasetmessages: + msg381158
2020-11-16 20:45:35hauntsaninjasetmessages: + msg381155
2020-11-16 20:24:08serhiy.storchakasetmessages: + msg381151
2020-11-16 18:48:47gvanrossumsetmessages: + msg381141
2020-11-16 09:25:29BTaskayasetnosy: + BTaskaya
messages: + msg381081
2020-11-16 08:38:24serhiy.storchakasetmessages: + msg381080
2020-11-16 05:29:20gvanrossumsetmessages: + msg381072
2020-10-21 06:53:00hauntsaninjasetmessages: + msg379197
2020-10-21 06:32:41serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg379196
2020-10-21 06:22:59hauntsaninjasetkeywords: + patch
stage: patch review
pull_requests: + pull_request21796
2020-10-21 02:24:55gvanrossumsetmessages: + msg379182
2020-10-21 01:48:07kjsetnosy: + kj
messages: + msg379179
2020-10-21 00:12:06rhettingersetnosy: + gvanrossum, levkivskyi
2020-10-20 21:48:49hauntsaninjacreate