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

Nick Coghlan ncoghlan at gmail.com
Sat Jun 30 04:27:37 EDT 2018

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

More information about the Python-Dev mailing list