[Tim] >> I'll channel that Guido would be happiest if this rule were followed: >> >> Given an assignment statement using "=", the meaning is the same if >> "=" is replaced with ":=".
[Chris] > That's broadly the intention. At the moment, there are two exceptions: > > 1) Augmented assignment isn't a thing Doesn't have to be :-) "Augmented assignment statement" is already a different thing than "assignment statement" (for example, in an augmented assignment statement, there is no chaining, and the sole target can' t be, e.g., a slice or any form of unpacking syntax). > 2) Chained assignment isn't a thing, which means that the assignments > operate right-to-left >> In particular, the expression at the far right is evaluated once, and >> - in case of chained assignments - is applied in turn to each target >> left-to-right. > I'll toy with this and see if I can implement it sanely. If so, > that'll eliminate one more distinction. >> Otherwise the semantics of "=" and ":=" can be very different indeed. > TBH, the common cases won't actually be much affected. Or at all! That's not the point here, though: if making assignment expressions work as exactly like assignment statements as possible is what's needed for the PEP to pass, it's the _annoying_ cases that have to be looked at. Personally, after considerable staring at my own code, I would be perfectly happy to settle for assignment expressions no fancier than identifier ":=" expression That alone covers over 99% of the cases I'd be tempted to use the new feature at all, and then gobs of general-case assignment-statement difficulties go away, including the "right-to-left or left-to-right?" distinction (there's no way to tell which order bindings happen in `x := y := z := 3` short of staring at the generated code). But so far I haven't gotten the impression that Guido is fond of that. He should be, though ;-) > You give this example: > > k := container[k] := value > > but that's not going to be more common. What I'm more likely to see is > something like this: Not about what's common, but about the full range of what's possible to express. ... [Nick] >>> Tuple unpacking: >>> >>> What's the result type for "a, b, c := range(3)"? Is it a range() >>> object? Or is it a 3-tuple? If it's a 3-tuple, is that 3-tuple "(1, 2, >>> 3)" or "(a, b, range(3))"? >> It's the range object range(3). Same as in: >> >> x = a, b, c = range(3) >> >> `x` is bound to the range object range(3). > At the moment, "x = a, b, c := range(3)" will set c to range(3), then > build a tuple of that with the existing values of a and b. You can, > however, parenthesize the (a, b, c) part, and then it'll behave as you > say. Which would be really annoying to "repair". >>> Whichever answers we chose would be surprising at least some of the >>> time, so it seems simplest to disallow such ambiguous constructs, such >>> that the only possible interpretation is as "(a, b, range(3))" >> That's why Guido would be happiest with the rule at the top. "The >> answers" can already be surprising at times with current assignment >> statements, but they are well defined. It would be mondo bonkers to >> make up entirely different subtle answers ;-) > Wholeheartedly agreed. I'd like Guido to chime in again, because I'm pretty sure he won't accept what's currently on the table. There are two plausible ways to repair that: 1. Continue down the road of making assignment expressions "exactly like" assignment statements in their full generality. 2. Back off and limit assignment expressions to what appears to be the overwhelmingly most common case motivated by looking at real code (as opposed to constructing examples to illustrate pitfalls & obscurities): identifier ":=" expression _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com