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

[Ivan Pozdeev]

On 23.06.2018 5:46, Steven D'Aprano wrote:
> On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:
>
>>>> I've started testing the proposed syntax when I teach. I don't have a
>>>> large
>>>> sample yet, but most students either dislike it or don't appreciate the
>>>> benefits. They state a clear preference for shorter, simpler lines at the
>>>> consequence of more lines of code.
> Of course they do -- they're less fluent at reading code. They don't
> have the experience to judge good code from bad.
>
> The question we should be asking is, do we only add features to Python
> if they are easy for beginners? It's not that I especially want to add
> features which *aren't* easy for beginners, but Python isn't Scratch and
> "easy for beginners" should only be a peripheral concern.

Python's design principles are expressed in the Zen. They rather focus 
on being no more complex than absolutely necessary, without prioritizing 
either beginners or old-timers ("simple is better than complex", 
"complex is better than complicated").

>>> This is partly because students, lacking the experience to instantly
>>> recognize larger constructs, prefer a more concrete approach to
>>> coding. "Good code" is code where the concrete behaviour is more
>>> easily understood. As a programmer gains experience, s/he learns to
>>> grok more complex expressions, and is then better able to make use of
>>> the more expressive constructs such as list comprehensions.
>>>
>> I don't think that's the only dynamic going on here. List comprehensions
>> are more expressive, but also more declarative and in Python they have nice
>> parallels with SQL and speech patterns in natural language. The concept of
>> a comprehension is separate from its particular expression in Python. For
>> example, Mozilla's array comprehensions in Javascript are/were ugly [0].
> Mozilla's array comprehensions are almost identical to Python's, aside
> from a couple of trivial differences:
>
>      evens = [for (i of numbers) if (i % 2 === 0) i];
>
> compared to:
>
>      evens = [i for i in numbers if (i % 2 == 0)]
>
> - the inexplicable (to me) decision to say "for x of array" instead of
>    "for x in array";
>
> - moving the expression to the end, instead of the beginning.
>
> The second one is (arguably, though not by me) an improvement, since it
> preserves a perfect left-to-right execution order within the
> comprehension.
>
>   
>> Students who are completely new to programming can see the similarity of
>> list comprehensions to spoken language.
> o_O
>
> I've been using comprehensions for something like a decade, and I can't
> :-)
>
> The closest analogy to comprehensions I know of is set builder notation
> in mathematics, which is hardly a surprise. That's where Haskell got the
> inspiration from, and their syntax is essentially an ASCIIfied version
> of set builder notation:
>
> Haskell: [(i,j) | i <- [1,2], j <- [1..4]]
>
> Maths:   {(i,j) : i ∈ {1, 2}, j ∈ {1...4}}
>
> I teach secondary school children maths, and if there's a plain English
> natural language equivalent to list builder notation, neither I nor any
> of my students, nor any of the text books I've read, have noticed it.
>
>
>
>

-- 
Regards,
Ivan