I don’t see how this helps much in situations with nested callables which are very common for decorators. I’m also unsure how this will work with situations where input and output are both callables and the signature is modified using paramspec. An example would be a decorator that adds/removes one argument. Is Concatenate[int, InttoIntFunction] a thing?
I also would ideally want a very light weight way to handle simple callables like (int) -> bool. This decorator solution of @Callable seems roughly as readable as existing solution of using callback protocols or a type alias. I took a quick scan of my team’s codebase and see about 150 callable vs like 1.5k optional. Optional is fairly high as a lot of our code has many arguments that can be disabled which I think is normal for ml/numerical libraries with tons of tuning settings. The most complex callable signatures tend to be decorators/decorator factories for us. Main place I find this useful is skimming other libraries type signatures and hovering in ides. Nice hover type hints is helpful over large blocks of callable brackets. I do find this syntactic sugar nice. I’m +0.5, mainly as while I think current callable generic is messy, I also think most of the people that write those type annotations are the ones that write a lot of them. Maybe that would change with better readability but right now heavy callable type usage feel like an advanced, uncommon thing. Part of it is also heavy functional style code isn’t that common in python. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EVE274LSWE5CDPJYW3VVVPJENVQIQMVM/ Code of Conduct: http://python.org/psf/codeofconduct/
