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

[Steven D'Aprano]

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.


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




-- 
Steve