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

[Ivan Pozdeev]

On 05.07.2018 2:52, Mike Miller 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 <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.

https://mail.python.org/pipermail/python-dev/2018-July/154343.html :
"Any construct that accepts an expression and uses its result but 
doesn't allow to insert an additional line in the middle qualifies."

If/when is not enough.

And https://mail.python.org/pipermail/python-dev/2018-June/154160.html 
disproves the "chosen often these days in new languages".

> We can also reuse the existing "EXPR as NAME" syntax that already 
> exists and is widely enjoyed.
>

For the record, with "as", Victor Stinner's examples from the 5 Jul 2018 
00:51:37 +0200 letter would look like:

while expr as x:

while input.readline() as line:

while (c//n as q) < n:

while (self.__read(1) as s) and s != NUL:

while (self.next() as tarinfo) is not None:
     pass

while (match() as m) and (m.end() as j) == i:


> 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

Very fitting, given the recent mentions of "dictatorship" and all :-)

>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru

-- 
Regards,
Ivan