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
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/ZDCSTHMZVSILZZMGI3GTTBTWB53ZRJOI/
Code of Conduct: http://python.org/psf/codeofconduct/
