On 4/19/2020 7:23 AM, Richard Damon wrote:
On 4/19/20 1:48 AM, Stephen J. Turnbull wrote:
Chris Angelico writes:
Except that render_template isn't one of my own functions. It's part of the templating engine (this is a Flask web app). There is no refactoring to do - that IS the correct way to call it.
So NOW you tell me! ;-) Just kidding: of course I recognized that as a library call. Of course cases where one calls a library function with a plethora of keyword arguments and large fraction of them are going to take same name variables as keyword arguments are going to exist. The question is are they frequent enough to justify an IMO ugly syntax change. There are a lot of other factors involved, such as why there are so many randomly-assorted variables that are nevertheless related by this function call, whether this particular call is repeated with the same objects (so that it might be worth wrapping it in a marshalling function with appropriate defaults), if it would be conceptually useful to have a library manager object that collects all of the assorted variables, and so on.
One thing that came to mind as I think about this proposal that may be something to think about. One of the key motivations of this proposal is to make nicer a call with a lot of key word arguments where the local variable name happens (intentionally) to match the keyword parameter name. IF we do something to make this type of call nicer, then there is now an incentive to make your local variables that are going to be passed into functions match the name of the keyword parameter. This incentive might push us from using what be a more descriptive name, which describes what we are doing in our particular case, to match the more generic name from the library.
There is also the issue that if we are building a function that might be used with another function, we will have an incentive to name our keyword parameters that there is a reasonable chance would also be passed to that other function with the same keyword name, even if that might not be the most descriptive name.
This will cause a slight reduction in readability of code, as cases of foo = phoo, start to stand out and get changed to just foo (by renaming the variable phoo). It is a natural outcome of you get what you make special cases for.
I agree: this is part of why I consider this whole proposal to be an anti-pattern. I'd expect a PEP to mention the above issues. Thanks for highlighting them.