On Thu, Mar 1, 2018 at 2:46 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 28 February 2018 at 15:18, Chris Angelico <rosuav@gmail.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.
Sure. Ultimately, it's like any other feature: it can be abused in ways that make no sense. You can write a list comprehension where you ignore the end result and work entirely with side effects; you can write threaded code that spawns threads and immediately joins them all; nobody's stopping you. In a non-toy example, assigning to the same name twice in one statement is almost certainly an error for other reasons, so I'm not too bothered by it here. I'll add something to the PEP about execution order. ChrisA