[Python-Dev] PEP 572, VF/B, and "Shark Jumping"

[Mike Miller]

Recently on Python-Dev:

On 2018-07-03 15:24, Chris Barker wrote:
 > On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico <rosuav at gmail.com
 >     On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka <storchaka at 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