
On Sun, Apr 19, 2020 at 09:28:28AM -0400, Eric V. Smith wrote: [...]
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.
If it is an anti-pattern for one method to duplicate the parameter names of another method, is it a pattern to intentionally differentiate the parameter names by using synonyms? I regularly -- not frequently, but often enough that it becomes a pain point -- have a situation where I have one or more public functions which call other functions with the same parameters. Here's a real signature from one of my functions where this occurs. def inspect(obj=_SENTINEL, pattern=None, *, dunder=True, meta=False, private=True, ignorecase=False, invert=False) It ends up calling a ton of methods that accept some or all of the same parameter names, using the `dunder=dunder` idiom. Today I learned this is an antipattern. For the record, earlier in this thread I considered making this same argument against this proposal because it would encourage people to rename their parameters to match those of other functions, but I deleted it. At least I hope I deleted it, because seeing it actually written down shows me that it's a really weak argument. Consistency of parameter names is more often a good thing than a bad thing. I don't know if that counts as a point in favour of this proposal, but I'm pretty sure it shouldn't count as a point against it. -- Steven