On Tue, Apr 21, 2020 at 11:01 AM M.-A. Lemburg email@example.com wrote:
On 21.04.2020 10:07, Alex Hall wrote:
On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg <firstname.lastname@example.org mailto:email@example.com> wrote:
In the use case discussed here, that namespace would be locals(), so you could just as well write
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.