On Nov 30, 2019, at 05:10, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Why "new" users? Because experienced users will have their "intuition" informed by their experience with "traditional" ways of expression as codified in identifiers and syntax. For example, while augmented assignment turns out to be useful to provide mutating operations and signal them to the reader, the increment operation is purely syntactic sugar compared to "i += 1" as a statement, but insufficiently powerful and orthogonal as an expression to add to Python. Yet C-experienced users frequently requested the increment operator.
I’m not sure this example really argues the case. To an experienced C programmer, both += and ++ are intuitive. But to a novice who’s never programmed, neither one is intuitive. The way to distinguish between them is to delve into the C programmers’ intuition and understand what drives it. First, ++ is used almost entirely as an expression in C, and the postfix form is only useful as an expression, but += is often used as a statement. But Python expressions (for the next few decades until :=, at least) normally don’t mutate things, except for explicit method calls which by convention return None. So neither of them should be an expression in Python, which is a strike against the C intuition for usability of ++ being transferable to Python, but not against +=. Furthermore, ++ is only useful on index-like values, and, unlike C, all of these are immutable in Python (at least until someone invents numpy index arrays as indexes), while += is useful on all numeric-like and sequence-like values, and the prototypical sequence-like type, list, is mutable. This is another strike against ++ but not +=. Of course that’s only two strikes. But now, when you’re balancing the cost (two extra methods, one of which is mildly confusing, vs. one, and prefix ++ requires an extra lookahead to distinguish from prefix +, but += and postfix ++ don’t) against the benefit… I don’t think Guido actually went through all of this in conscious detail, much less on paper (the way we would if someone were proposing ++ and += in the age of PEPs and -ideas and -dev), but I think it’s the main underlying reason he decided that borrowing += but not ++ made sense for Python. Not imagining whether new users would clamor first += but not ++, or be able to learn each when they see it, but knowing that C programmers would find them both intuitive but that their intuition for ++ doesn’t make sense for Python while their intuition for += does.