On Mon, Sep 10, 2018 at 08:05:22AM +0200, Anders Hovmöller wrote: > I just realized I have another question for you:
Is that a generic you or just me personally? :-) > If you had to chose which one would you prefer: > > f(*, a b, c) > > or: > > f(=a, =b, =c) > > ? I can't say I particularly like either syntax, but if I had a gun pointed at my head and had to choose one, I'd *probably* prefer something like this: open("myfile.txt", 'r', =buffering, =encoding, =errors, newline='\r', =closefd, opener=get_opener()) over this: open("myfile.txt", 'r', *, buffering, encoding, errors, newline='\r', closefd, opener=get_opener()) In the second case, the * is too easy to miss, leaving us with what looks like a confusing mix of positional and keyword arguments. Hmmm... a thought comes to mind... Suppose we had a wild-card symbol that simply told the parser to use the same string as that on the left hand side of the = sign, that might be promising. For the sake of illustration, I'm going to use the Unicode Snowman symbol, but that's just a place-holder. ☃ copies the token from the left hand side of the = to the right hand side. It is a syntax error if it doesn't follow an = sign. Then we could be (slightly) concise AND explicit: open("myfile.txt", 'r', buffering=☃, encoding=☃, errors=☃, newline='\r', closefd=☃, opener=get_opener()) would expand to: open("myfile.txt", 'r', buffering=buffering, encoding=encoding, errors=errors, newline='\r', closefd=closefd, opener=get_opener()) But honestly, this feels Perlish to me, or something that belongs in a personal pre-processor rather than the language. (Maybe we should embrace the concept of a Python pre-processor?) > I know you’re clearly against the entire idea but it seems we should > prefer the least disliked alternative in such a scenario. I accept this is a pain point for some people and some code bases. I'm not convinced it is painful enough to need a language-wide syntactic solution (but I don't have any better solution except "refactor until the pain goes away"), or that the benefit outweighs the real and potential costs. I wouldn't quite describe it as being "against the entire idea". It's not that I'm against the very idea of improving parameter handling in Python. I just don't think this is the way. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/