Named arguments confer many benefits by promoting explicit is better than implicit, thus increasing readability and minimising the risk of inadvertent transposition. However, the syntax can become needlessly repetitive and verbose.
I don’t know what the SC will think of this proposal, and I don’t have time to do a lot of mentoring in this area, but if a few folks here will come together and submit a PEP (following the process from PEP 1) and you need a sponsor you can put my name in. I personally prefer the syntax foo(x=, y=).
I think the arguments presented this time around are the most motivating (at least to me). In particular, I like this one: “Encourages authors to use the same variable name when calling a function as the argument”. That’s something I will intentionally fix if argument names drift apart. In my opinion, it is beneficial to have syntax that induces coders to do this.
I don’t think this argument was suggested the last couple times this was proposed.
… though I suspect that this is nothing more than a plain vanilla NameError. Am I understanding you correctly, and you mean code like this?
x = 1234 # no y
func(x=, y=) # or func(=x, =y) if that's the chosen syntax
If so, it should be no different from the longhand line above it, or any other attempt to reference a variable that doesn’t exist. Obviously static analysis tools will have to be taught about the new syntax, but that’s the case for all syntax.
Or were there other recommendations you had in mind?
Yeah, there’s definitely value in catching this sort of thing statically. I’ve no idea which checkers report on this (I gave MyPy a quick whirl and it didn’t report it, but that’s with default settings so maybe that can be turned on), but regardless, it should be able to be reported on regardless of this particular piece of syntax.