<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:<br>
<br>
> I have a working implementation for a new syntax which would make <br>
> using keyword arguments a lot nicer. Wouldn't it be awesome if instead <br>
> of:<br>
> <br>
> foo(a=a, b=b, c=c, d=3, e=e)<br>
> <br>
> we could just write:<br>
> <br>
> foo(*, a, b, c, d=3, e)<br>
> <br>
> and it would mean the exact same thing?<br>
<br>
No.<br>
<br>
<br>
> This would not just be shorter but would create an incentive for<br>
> consistent naming across the code base. <br>
<br>
You say that as if consistent naming is *in and of itself* a good thing, <br>
merely because it is consistent.<br>
<br>
I'm in favour of consistent naming when it helps the code, when the <br>
names are clear and relevant. But why should I feel bad about failing to <br>
use the same names as the functions I call? If some library author names <br>
the parameter to a function "a", why should I be encouraged to use <br>
that same name *just for the sake of consistency*?<br></blockquote><div><br></div><div>I've been asking this same question on the Javascript/ES6 side of my work</div><div>ever since unpacking was introduced there which baked hash-lookup into <br></div><div>the unpacking at a syntax level.</div><div><br></div><div>In that world its impacted this same encouragement of "consistency" between</div><div>local variable names and parameters of called functions and it certainly seems</div><div>popular in that ecosystem. The practice still feels weird to me and I'm on the fence</div><div>about it.</div><div><br></div><div>Although, to be honest, I'm definitely leaning towards the "No, actually, it is a</div><div>good thing." I grew up, development-speaking, in the Python world with a</div><div>strong emphasis drilled into me that style constraints make better code and</div><div>maybe this is just an extension of that.</div><div><br></div><div>Of course, you might not always want the same name, but it is only encouraged</div><div>not required. You can always rename variables.</div><div><br></div><div>That said... I'm not actually a fan of the specific suggested syntax:</div><div><br></div><div>> foo(*, a, b, c, d=3, e)</div><div><br></div><div>I just wanted to give my two cents on the name consistency issue.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> So the idea is to generalize the * keyword only marker from function <br>
> to also have the same meaning at the call site: everything after * is <br>
> a kwarg. With this feature we can now simplify keyword arguments <br>
> making them more readable and concise. (This syntax does not conflict <br>
> with existing Python code.)<br>
<br>
It's certainly more concise, provided those named variables already <br>
exist, but how often does that happen? You say 30% in your code base.<br>
<br>
(By the way, well done for writing an analysis tool! I mean it, I'm not <br>
being sarcastic. We should have more of those.)<br>
<br>
I disagree that f(*, page) is more readable than an explicit named <br>
keyword argument f(page=page).<br>
<br>
My own feeling is that this feature would encourage what I consider a <br>
code-smell: function calls requiring large numbers of arguments. Your <br>
argument about being concise makes a certain amount of sense if you are <br>
frequently making calls like this:<br>
<br>
# chosing a real function, not a made-up example<br>
open(file, mode=mode, buffering=buffering, encoding=encoding, <br>
errors=errors, newline=newline, closefd=closefd, opener=opener)<br>
<br>
If 30% of your function calls look like that, I consider it a <br>
code-smell.<br>
<br>
The benefit is a lot smaller if your function calls look more like this:<br>
<br>
open(file, encoding=encoding)<br>
<br>
and even less here:<br>
<br>
open(file, 'r', encoding=self.encoding or self.default_encoding, <br>
errors=self.errors or self.default_error_handler)<br>
<br>
for example. To get benefit from your syntax, I would need to <br>
extract out the arguments into temporary variables:<br>
<br>
encoding = self.encoding or self.default_encoding<br>
errors = self.errors or self.default_error_handler<br>
open(file, 'r', *, encoding, errors)<br>
<br>
which completely cancels out the "conciseness" argument.<br>
<br>
First version, with in-place arguments:<br>
1 statement<br>
2 lines<br>
120 characters including whitespace<br>
<br>
Second version, with temporary variables:<br>
3 statements<br>
3 lines<br>
138 characters including whitespace<br>
<br>
<br>
However you look at it, it's longer and less concise if you have to <br>
create temporary variables to make use of this feature.<br>
<br>
<br>
-- <br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>