I think I'll bow out of this now. It's just too tedious. Like here:
[Nick] > I never said the motivation was to gain performance relative to the > two-statement version - I said the motivation given in the PEP is to > gain performance relative to the *repeated subexpression* version, > *without* making the transition to the already supported two-statement > version. This is what you wrote: >> "NAME := EXPR" exists on a different level of complexity, since it >> adds name binding in arbitrary expressions for the sake of minor >> performance improvement in code written by developers that are >> exceptionally averse to the use of vertical screen real estate, I'm not telepathic, so took it for it what said. It didn't say a word about "repeated expressions", nor a word about "two-statement versions" It did say "minor" performance improvements, which sure suggested to me that you had in mind the tiny changes in bytecode that can result from squashing a current two-statement spelling into a one-statement form with an embedded assignment. That fit both "minor performance improvement" and "vertical screen space", which were the only the two clues I had to go on. In the example you eventually gave in a later message, the performance difference was more on the order of a factor 2 (regexp searches can be expensive indeed), which matches nobody's idea of "minor". So the use of "minor" wholly ruled out in my mind that you had _anything_ akin to your eventual example in mind. For the rest, sure, words could be added to the PEP without end. At least some of the points I covered were telegraphically mentioned in my Appendix, although I'll grant that nobody else is telepathic either ;-) For the question: > > The remaining point of contention is only the "Inevitable cost of > > change" one: given the level of disruption this will cause in the way > > that Python gets taught to new users, is it giving a commensurate > > pay-off in increased semantic expressiveness? > > > > My answer to that question remains "No", while your answer is either > > "Yes" or "I don't see why that should matter" (I'm genuinely unsure > > which). I don't know, and I'm not qualified to guess - I don't teach Python to new users for a living. Decades ago I tutored "advanced" engineering undergrads in a variety of science-y subjects, and was routinely surprised by what broke their brains. I have noted that assignment expressions have been part of a great many languages for decades (this isn't cutting edge tech), questions about them are conspicuous by absence on StackOverflow (everyone else seems to teach them effectively), and skimming various online teaching materials for other languages convinced me that none of those professional educators thought it needed more than a page to teach (and to teach them with relatively few words). There's really not much to them: people have to learn what binding means in Python regardless, pretty much starting in the first hour, yes? "Binding" on its own is the hard part. If they don't drop out and stick around for the 10-minute lesson on assignment expressions 3 weeks later, will _that_ finally break their brains? "Wow - it not only binds the name, but ALSO returns the object that was bound?! I just can't take it - please, let's go back to the lesson on metaclasses" just doesn't seem likely to me ;-) At heart, ":=" could make a good case for being the simplest of all Python's operators. It does no computation at all, and you don't even have to worry about a dunder method changing its meaning depending on context. So, ya, when someone claims they'll make Python significantly harder to teach, I'm skeptical of that claim. Which does not mean I believe it's wrong - it means I'm skeptical. I would also be skeptical of a claim that teaching them would be no trouble at all, except nobody has made such a claim ;-)
_______________________________________________ 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
