[Python-Dev] Any grammar experts?

[Paul Moore]

On 26 January 2015 at 18:12, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I have to agree with Barry. While the following is obvious even without
> having ever used it:
>
>   a, b, *c = range(5)
>
> the following makes me scratch my head and I can't seem to guess what
> the *intent* is - which is very problematic when e.g. reviewing code:
>
>   [*x for x in it]
>   {**x for x in it}
>
>   (and other similar things)
>
> I also think the multiple-starargs function calls are completely
> overboard:
>
>   f(**someargs, **someotherargs)
>
> (I might add I've never felt any need for those)

These cases made little sense to me when I first saw them here, but a
quick read of the PEP made them feel reasonably straightforward - *x
is essentially splicing in a list, and a sequence of **x is a sort of
"if you don't find it here, look here" fallback mechanism. Also, real
examples would presumably have clearer variable names, and maybe even
an explanatory comment. And if they don't, they should do (and a code
review that said "this is confusing, add a comment" would seem
entirely appropriate to me).

There *are* some nastily non-intuitive corner cases (for example, if
from_env={'a':12} and from_config={'a':13}, I don't have any sort of
intuition as to what a would be in f(**from_env, **from_config). I'd
go with 12 because the PEP links multiple **-unpackings with
collections.ChainMap, but I wouldn't dare rely on that guess).

My feeling is that the PEP is essentially fine, but the
"Disadvantages" section needs expansion to note (in a reasonable
amount of detail) that it's possible to write very obfuscated code
with these constructs. It should also call out the corner cases and
note that the behaviour, although following from the rules, isn't
obvious. Personally, I don't think the resulting disadvantages are so
bad that the PEP needs to be rejected, it's just a matter of being
open about the potential for unclear code.

Paul