- It’s as explicit as you can get. It says, run function
fwhile binding the variable with the namexto the parameter with the namex. Equivalently, it says run runctionfwhile binding the variablexas the argument into the parameterx. - My understand from the PEP is that
f(x=)is exactly syntactically equivalent tof(x=x). So that anything that can be done wih the latter can be done with the former.
Type checking example:
def foo(x: float):
...
x = "Hello World!"
foo(x=) # Expected type 'float', got 'str' instead.
Refactoring variable or parameter names is a little tricker. I would expect if I refactor x to be named y in foo that my IDE would do the following:
def foo(y: float):
...
x = "Hello World!"
foo(y=x) # Expected type 'float', got 'str' instead.
and I refactored variable x to z that my IDE would do
def foo(x: float):
...
z = "Hello World!"
foo(x=z) # Expected type 'float', got 'str' instead.
That is, it would detect the breaking of the variable name ↔ parameter name matching required for PEP 736 abbreviation and thus stop doing it.
I wouldn’t be opposed to my tools being able to detect foo(x=x) and suggest I convert it to foo(x=), though I know others would be, so I hope that any tool that makes those suggestions would be configurable to suppress that suggestion.
Here’s an important downside: Right now in my IDE if I have
def foo(x):
...
x = 42
foo(x=x)
I can click on the first x in x=x and then hit a hotkey that will jump my cursor to the x in the foo() function definition. I can also click on the second x in x=x and hit a hotkey that will jump my cursor to the x = 42 variable definition (or maybe its last modification? I’m not sure). If PEP 736 is used so that the code becomes foo(x=) it is now ambiguous where the hotkey should send me when I select the x. Perhaps it could treat placing the cursor after the equals sign the same way it used to treat clicking the second x in x=x. In any case, this IDE feature will become slightly less nice with PEP 736 I think.