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

[Guido van Rossum]

On Sun, Jun 24, 2018 at 2:41 PM Michael Selik <mike at selik.org> wrote:

> This thread started with a request for educator feedback, which I took to
> mean observations of student reactions. I've only had the chance to test
> the proposal on ~20 students so far, but I'd like the chance to gather more
> data for your consideration before the PEP is accepted or rejected.
>

Sure. Since the target for the PEP is Python 3.8 I am in no particular
hurry. It would be important to know how you present it to your students.


> On Sun, Jun 24, 2018 at 11:09 AM Steven D'Aprano <steve at pearwood.info>
> wrote:
>
>> Remember, the driving use-case which started this (ever-so-long)
>> discussion was the ability to push data into a comprehension and then
>> update it on each iteration, something like this:
>>
>>     x = initial_value()
>>     results = [x := transform(x, i) for i in sequence]
>>
>
> If that is the driving use-case, then the proposal should be rejected. The
> ``itertools.accumulate`` function has been available for a little while now
> and it handles this exact case. The accumulate function may even be more
> readable, as it explains the purpose explicitly, not merely the algorithm.
> And heck, it's a one-liner.
>
>     results = accumulate(sequence, transform)
>

I think that's a misunderstanding. At the very least the typical use case
is *not* using an existing transform function which is readily passed to
accumulate -- instead, it's typically written as a simple expression (e.g.
`total := total + v` in the PEP) which would require a lambda.

Plus, I don't know what kind of students you are teaching, but for me,
whenever the solution requires a higher-order function (like accumulate),
this implies a significant speed bump -- both when writing and when reading
code. (Honestly, whenever I read code that uses itertools, I end up making
a trip to StackOverflow :-).


> The benefits for ``any`` and ``all`` seem useful. Itertools has
> "first_seen" in the recipes section.
>

(I think you mean first_true().)


> While it feels intuitively useful, I can't recall ever writing something
> similar myself. For some reason, I (almost?) always want to find all
> (counter-)examples and aggregate them in some way -- min or max, perhaps --
> rather than just get the first.
>

I trust Tim's intuition here, he's written about this.

Also, Python's predecessor, ABC, had quantifiers (essentially any() and
all()) built into the language, and the semantics included making the first
(counter-)example available (
https://homepages.cwi.nl/~steven/abc/qr.html#TESTS). Essentially

IF SOME x IN values HAS x < 0:
    WRITE "Found a negative x:", x

equivalently

IF EACH x IN values HAS x >= 0:
    # ...
ELSE:
    WRITE "Found a negative x:", x

and even

IF NO x IN values HAS x < 0:
    # ...
ELSE:
    WRITE "Found a negative x:", x


> Even so, if it turns out those uses are quite prevalent, wouldn't a new
> itertool be better than a new operator? It's good to solve the general
> problem, but so far the in-comprehension usage seems to have only a handful
> of cases.
>

Perhaps, but IMO the new itertool would be much less useful than the new
syntax.


> On Fri, Jun 22, 2018 at 9:14 PM Chris Barker via Python-Dev <
> python-dev at python.org> wrote:
>
>> again, not a huge deal, just a little bit more complexity
>>
>
> I worry that Python may experience something of a "death by a thousand
> cuts" along the lines of the "Remember the Vasa" warning. Python's greatest
> strength is its appeal to beginners. Little bits of added complexity have a
> non-linear effect. One day, we may wake up and Python won't be recommended
> as a beginner's language.
>

I don't think that appeal to beginners is Python's greatest strength. I'd
rather say that it is its appeal to both beginners and experts (and
everyone in between). If true appeal to beginners is needed, Scratch or
Processing would probably be better.


> On Fri, Jun 22, 2018 at 7:48 PM Steven D'Aprano <steve at pearwood.info>
> wrote:
>
>> On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:
>>
>> Of course they do -- they're less fluent at reading code. They don't
>> have the experience to judge good code from bad.
>>
>
> On the other hand, an "expert" may be so steeped in a particular
> subculture that [they] no longer can distinguish esoteric from intuitive.
> Don't be so fast to reject the wisdom of the inexperienced.
>

Nor should we cater to them excessively though. While the user is indeed
king, it's also well known that most users when they are asking for a
feature don't know what they want (same for kings, actually, that's why
they have advisors :-).


> 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.
>>
>
> On the contrary, I believe that "easy for beginners" should be a major
> concern.  Ease of use has been and is a, or even the main reason for
> Python's success. When some other language becomes a better teaching
> language, it will eventually take over in business and science as well.
> Right now, Python is Scratch for adults. That's a great thing. Given the
> growth of the field, there are far more beginner programmers working today
> than there ever have been experts.
>

I'm sorry, but this offends me, and I don't believe it's true at all.
Python is *not* a beginners language, and you are mixing ease of use and
ease of learning. Python turns beginners into experts at an unprecedented
rate, and that's the big difference with Scratch.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180624/ed812902/attachment-0001.html>