Please, Mike, can you stop? The race is over and your horse has lost. I really value all the input I've received during the months of discussion (including your research into what other languages do), but in the end my "evaluation function" (to use somewhat hip lingo :-) is different from yours. For a while I seriously considered "EXPR as NAME", but when comparing examples written in one style vs. another I just liked "NAME := EXPR" better every time. In addition to the problems with "with" (which everyone has read about already) and the general rule that "as" is preceded by specific syntax that predicts it (i.e. "import", "except" or "with"), I found that when skimming the code it was easier to miss the definition of NAME with the "as" form than with the ":=" variant.
There was also someone who posted that they believe that the problems with evaluation order (alluded to in the PEP) would be solved by the "as" form. However that's not the case -- in fact I believe that Python would have to generate exactly the same bytecode for "EXPR as NAME" as for " NAME := EXPR", since in both cases it comes down to "LOAD EXPR; STORE NAME" (in pseudo bytecode). So neither form supports things like "x == (x := f())" since this comes down to LOAD x LOAD f CALL STORE x COMPARE with either syntax variant (again, in pseudo bytecode). On Wed, Jul 4, 2018 at 5:09 PM Mike Miller <python-...@mgmiller.net> wrote: > Recently on Python-Dev: > > On 2018-07-03 15:24, Chris Barker wrote: > > On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico <ros...@gmail.com > > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka < > storch...@gmail.com> > > > > > I believe most Python users are not > > > professional programmers -- they are sysadmins, scientists, > hobbyists > > > and kids -- > > > > [citation needed] > > > > fair enough, but I think we all agree that *many*, if not most, Python > users > > are "not professional programmers". While on the other hand everyone > involved > > in discussion on python-dev and python-ideas is a serious (If not > > "professional") programmer. > > > Python Audience - wants clarity: > > Not sure I'd say that most users are not professionals, but one major > strength > of Python is its suitability as a teaching language, which enlarges the > community every year. > > Additionally, I have noticed a dichotomy between prolific "C programmers" > who've > supported this PEP and many Python programmers who don't want it. While > C-devs > use this construct all the time, their stereotypical Python counterpart is > often > looking for simplicity and clarity instead. That's why we're here, folks. > > > Value - good: > > Several use cases are handled well by PEP 572. However it has been noted > that > complexity must be capped voluntarily relatively early—or the cure soon > becomes > worse than the disease. > > > Frequency - not much: > > The use cases for assignment-expressions are not exceedingly common, > coming up > here and there. Their omission has been a very mild burden and we've done > without for a quarter century. > > Believe the authors agreed that it won't be used too often and won't > typically > be mis- or overused. > > > New Syntax - a high burden: > > For years I've read on these lists that syntax changes must clear a high > threshold of the (Value*Frequency)/Burden (or VF/B) ratio. > > Likewise, a few folks have compared PEP 572 to 498 (f-strings) which some > former > detractors have come to appreciate. Don't believe this comparison applies > well, > since string interpolation is useful a hundred times a day, more concise, > clear, > and runs faster than previous functionality. Threshold was easily cleared > there. > > > Conclusion: > > An incongruous/partially redundant new syntax to perform existing > functionality > more concisely feels too low on the VF/B ratio IMHO. Value is good though > mixed, frequency is low, and burden is higher than we'd like, resulting in > "meh" > and binary reactions. > > Indeed many modern languages omit this feature specifically in an effort > to > reduce complexity, ironically citing the success of Python in support. > Less is > more. > > > Compromise: > > Fortunately there is a compromise design that is chosen often these days > in new > languages---restricting these assignments to if/while (potentially > comp/gen) > statements. We can also reuse the existing "EXPR as NAME" syntax that > already > exists and is widely enjoyed. > > This compromise design: > > 1 Handles the most common cases (of a group of infrequent cases) > 0 Doesn't handle more obscure cases. > 1 No new syntax (through reuse) > 1 Looks Pythonic as hell > 1 Difficult to misuse, complexity capped > > Score: 4/5 > > PEP 572: > > 1 Handles the most common cases (of a group of infrequent cases) > 1 Handles even more obscure cases. > 0 New syntax > 0 Denser look: more colons, parens, expression last > 0 Some potential for misuse, complexity uncapped > > Score: 2/5 > > > Thanks for reading, happy independence, > -Mike > > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
