[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