Steven D'Aprano wrote:
In comparison, Mark's version: @Callable def IntToIntFunc(a:int)->int: pass # in the type declaration func: IntToIntFunc uses 54 characters, plus spaces and newlines (including 7 punctuation characters); it takes up three extra lines, plus a blank line. As syntax goes it is double the size of Callable.
I think it takes only the characters needed to write the name IntToIntFunc. The @callable def section is a one-time definition, and not logically part of each function definition where it is used. I get that some people prefer an inline lambda to a named function, and others hate naming an infrastructure function, but ... Why are you even bothering to type the callback function? If it is complicated enough to be worth explicitly typing, then it is complicated enough to chunk off with a name. I won't say it is impossible to understand a function signature on the first pass if it takes several lines and whitespace to write ... but it is much easier when the the declaration is short enough to fit on a single line. An @ on the line above complicates the signature parsing, but can be mentally processed separately. The same is true of a named-something-or-other in the middle. Having to switch parsing modes to understand an internal ([int, float, int] -> List[int]), and then to pop that back off the stack is much harder. Hard enough that you really ought to help your reader out with a name, and let them figure out what that names means separately, when their brain's working memory isn't already loaded with the first part of your own function, but still waiting for the last part.
It separates the type declaration from the point at which it is used, potentially far away from where it is used.
The sort of code that passes around functions tends to pass around many functions, but with only a few signatures. If this is really the only time you'll need that signature (not even when you create the functions that will be passed from a calling site?), then ... great. But be nice to your reader anyhow, unless the signature is really so simple that the type-checking software should infer it for you. Then be nice by leaving it out as cruft. [As an aside, I would see some advantage to def myfunc(f:like blobfunc) pointing to an examplar instead of a specifically constructed function-type. You discuss this later as either ... f:blobfunc ... or ... f:blobfunc=blobfunc ... and I would support those, if other issues can be worked out.] -jJ