On 28 February 2018 at 15:18, Chris Angelico email@example.com wrote:
a = (2 as a)
there is a temporary variable 'a', which gets assigned 2, and the SLNB is evaluated as 2, which should then get assigned back to the local variable 'a'. In other words, the final print from `f()` above should be 2, not 1. (Slightly different names would help avoid confusion when referencing different locations of the PEP.)
Except that assignment is evaluated RHS before LHS as part of a single statement. When Python goes to look up the name "a" to store it (as the final step of the assignment), the SLNB is still active (it's still the same statement - note that this is NOT expression-local), so it uses the temporary.
Honestly, though, it's like writing "a = a++" in C, and then being confused by the result. Why are you using the same name in two assignments? Normal code shouldn't do this. :)
Eww. I can understand the logic here, but this sort of weird gotcha is precisely why people dislike C/C++ and prefer Python. I don't consider it a selling point that this proposal allows Python coders to make the sort of mistakes C coders have suffered from for years.
Can you make sure that the PEP includes a section that covers weird behaviours like this as problems with the proposal? I'm happy if you just list them, or even say "while this is a potential issue, the author doesn't think it's a major problem". I just don't think it should be forgotten.