On Fri, Dec 24, 2021 at 01:28:44PM +1100, Steven D'Aprano wrote:
Honestly, I cannot see a single positive to using `def` statements. ... This is not a rhetorical question.
Hmm, I think I may have come up with one. If we did teach type checkers to use actual functions as prototypes, that would allow the same function object to do double duty as the type-hint (as a prototype) and as an implementation of that prototype. So if you wanted a function that has the same signature as builtin `print`, you could just say something like: def traverse_graph( g: Graph, maxdepth: int = -1, # Same signature as print, defaults to print visitor: print = print, ) -> None: instead of having to replicate print's signature. The duplication `: print = print` is a bit on the nose, but not too much. And maybe type-checkers could infer that if a parameter defaults to a function, its type-hint should clearly be the same as the default? This would require builtins to gain annotations, of course. Which they don't currently have :-( And for the avoidance of doubt, I am not suggesting this be limited to only builtin functions. Any function with annotations would work. So to my mind, that moves Mark's proposal into the category of an independent new feature separate to PEP 677, rather than a competitor or alternative proposal: * Teach type-checkers to use functions made with `def` as function prototypes (regardless of what the body is). * Likewise for classes (use the `__call__` method's signature as the prototype). while PEP 677 remains as a nice-looking shorter syntax for in-place anonymous Callable Types. I remain strongly -1 on `def ...` as an alternative to PEP 677, I don't think that the `def` syntax makes a good alternative to either Callable or the proposed arrow syntax. But being able to use an existing function, complete with implementation in the body, as a prototype, yeah, I'll buy that. -- Steve