On Tue, Apr 21, 2020 at 11:01 AM M.-A. Lemburg <mal@egenix.com> wrote:
On 21.04.2020 10:07, Alex Hall wrote:
>
>
> On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg <mal@egenix.com
> <mailto:mal@egenix.com>> wrote:
>
>     In the use case discussed here, that namespace would be
>     locals(), so you could just as well write render_template(**locals()),
>
>
> Doing that gets in the way of tools. At the very least it makes it
> impossible to highlight accidentally unused variables.
  
True, but when rendering a template, you normally don't care
about unused variables -- just about undefined ones :-)

I always care about unused variables, because they tend to be a red flag that I meant to use them somewhere but made a mistake, e.g. I used the wrong variable instead.
 
> We went through this discussion already with Stephen J Turnbull. I've
> given concrete examples from the CPython repo of this pattern, where you
> can see all the context. Feel free to pick any of them (except the log
> level thing, an enum is the right solution there) and explain exactly
> how you would reduce same-naming.

I am aware of the pattern and it's needed in cases where you
don't have a way to influence the API, e.g. when using a 3rd
party lib which wants to receive configuration via function
call parameters only.

Where you do have full control, it's pretty easy to get around
the need to write var1=var1, var2=var2, etc. by using namespace
or context objects, keyword dict manipulation, a better object
oriented design or dedicated configuration APIs.

We're not talking about a third party lib, and you do have plenty of control. Several of those calls are to internal, protected APIs.