[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan]

On 29 June 2018 at 08:42, Chris Barker via Python-Dev
<python-dev at python.org> wrote:
> On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> Did adding ternary `if` (truepart if expression else falsepart) complicate
>> the language significantly?
>
>
> I don't think so -- no. For two reasons:
>
> 1) the final chosen form is kind of verbose, but therefor more like
> "executable pseudo code" :-) As apposed to the C version, for instance.
>
> 2) it added one new construct, that if, when someone sees it for the first
> (or twenty fifth) time and doesn't understand it, they can look it up, and
> find out. and it only effects that line of code.
>
> So adding ANYTHING does complicate the language, by simply making it a bit
> larger, but some things are far more complicating than others.

It's worth noting that without the bug prone "C and A or B" construct
(which gives the wrong result when "not A" is True), we'd likely never
have gotten "A if C else B" (which gives the right result regardless
of the truth value of A). In the case of PEP 308, the new construction
roughly matched the existing idiom in expressive power, it just
handled it correctly by being able to exactly match the developer's
intent.

"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, and
making a couple of moderately common coding patterns (loop-and-a-half,
if-elif-chains with target binding) more regular, and hence easier to
spot.

I think the current incarnation of PEP 572 does an excellent job of
making the case that says "If we add assignment expressions, we should
add them this particular way" - there are a lot of syntactic and
semantic complexities to navigate, and it manages to make its way
through them and still come out the other side with a coherent and
self-consistent proposal that copes with some thoroughly quirky
existing scoping behaviour.

That only leaves the question of "Does the gain in expressive power
match the increase in the cognitive burden imposed on newcomers to the
language?", and my personal answer to that is still "No, I don't think
it does". It isn't my opinion on that that matters, though: I think
that's now going to be a conversation between Guido and folks that are
actively teaching Python to new developers, and are willing to get
their students involved in some experiments.

Cheers,
Nick.

P.S. It does make me wonder if it would be possible to interest the
folks behind https://quorumlanguage.com/evidence.html in designing and
conducting fully controlled experiments comparing the
comprehensibility of pre-PEP-572 code with post-PEP-572 code *before*
the syntax gets added to the language :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia