On Nov 30, 2019, at 05:10, Stephen J. Turnbull <turnbull.stephen...@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. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CFOOQEU6U2MCMSHJV7GQFLTD4XGS37Z5/ Code of Conduct: http://python.org/psf/codeofconduct/
