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 <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.
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@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
_______________________________________________
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
