[Python-ideas] Keyword only argument on function call
Steven D'Aprano
steve at pearwood.info
Mon Sep 10 08:24:10 EDT 2018
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
More information about the Python-ideas
mailing list