Steve wrote: > With the usual disclaimer that I understand it will never be manditory > to use this syntax, nevertheless I can see it leading to the "foolish > consistency" quote from PEP 8.
> "We have syntax to write shorter code, shorter code is better, > so if we want to be Pythonic we must design our functions to use > the same names for local variables as the functions we call." > -- hypothetical blog post, Stackoverflow answer, > opinionated tutorial, etc. > I don't think this is a pattern we want to encourage. Steve's "hypothetical blog post" is a pattern he doesn't like, and he said that it's not a pattern we want to encourage. And he proceeds to demolish this pattern, in the rest of his post. According to https://en.wikipedia.org/wiki/Straw_man <quote> The typical straw man argument creates the illusion of having completely refuted or defeated an opponent's proposition through the covert replacement of it with a different proposition (i.e., "stand up a straw man") and the subsequent refutation of that false argument ("knock down a straw man") instead of the opponent's proposition. </quote> So what was the original proposition. I summarise from the original post. It was to allow foo(*, a, b, c, d=3, e) as a shorthand for foo(a=a, b=b, c=c, d=3, e=e) And also that on two big code bases about 30% of all arguments would benefit from this syntax. And also that it would create an incentive for consistent naming across the code base. To me, the "30% of all arguments" deserves more careful examination. Does the proposal significant improve the reading and writing of this code? And are there other, perhaps better, ways of improving this code? I'm very keen to dig into this. I'll start a new thread for this very topic. -- Jonathan _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/