On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote:
On Apr 20, 2020, at 01:06, M.-A. Lemburg firstname.lastname@example.org wrote:
The current version already strikes me as way too complex. It's by far the most complex piece of grammar we have in Python:
funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT] func_body_suite
But nobody’s proposing changing the function definition syntax here, only the function call syntax. Which is a lot less hairy. It is still somewhat hairy, but nowhere near as bad, so this argument doesn’t really apply.
True, I quoted the wrong part of the grammar for the argument, sorry. I meant this part:
which is simpler, but not really much, since the devil is in the details.
We already have shortcuts in the form of * and ** for function calls, both putting the unpacking on the calling side of the function, rather than inside the function where it would arguably be much cleaner to add.
You're now proposing to add yet another shortcut to avoid having to translate local variables to possibly the same keyword arguments used by the function.
But arguing that f(a=, b=, c=, d=) is any better than f(a=a, b=b, c=c, d=d) does not really solve anything.
The problem is with the code design, not with the syntax.
You'd be better off putting your variables combined into a context object or container and pass that around:
In many cases, you can avoid passing around any of these variables, by simply using an object rather than a function oriented approach. The variables would then become object attributes, so calling f() becomes:
and the method f would get it's context straight from the object attributes of task -- without any arguments to pass in.