On 21.04.2020 06:56, Chris Angelico wrote:
On Tue, Apr 21, 2020 at 9:27 AM M.-A. Lemburg firstname.lastname@example.org wrote:
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.
Please explain how this will help the case of render_template and similar, where the function accepts ANY keyword arguments, and then passes them along to the template. Do I need to package everything up into a dictionary? And how would that actually improve things, given that I'd still need to do the exact same thing to construct that dictionary? Every template has its own unique variables, and most of them come straight from the calling function, with the same names.
This is NOT going to be a consistent object with the same attributes. That simply is not the use-case here. We already have that.
A render_template() function which has **kws as parameter can take any number of keyword parameters, including ones which are not used in the template.
Those functions will usually take a namespace object as basis for rendering the final string.
In the use case discussed here, that namespace would be locals(), so you could just as well write render_template(**locals()), or better: use a namespace object, fill this with the right values and pass in render_template(namespace).