[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
mike at selik.org
Sun Jun 24 17:35:46 EDT 2018
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.
On Sun, Jun 24, 2018 at 11:09 AM Steven D'Aprano <steve at pearwood.info>
> 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)
The benefits for ``any`` and ``all`` seem useful. Itertools has
"first_seen" in the recipes section. 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.
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
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.
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 he no longer can distinguish esoteric from intuitive. Don't be so fast
to reject the wisdom of the inexperienced.
> 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.
Mozilla's array comprehensions are almost identical to Python's, aside
> from a couple of trivial differences:
I can't prove it, but I think the phrase ordering difference is not trivial.
> Students who are completely new to programming can see the similarity of
> > [Python] list comprehensions to spoken language.
> I've been using comprehensions for something like a decade, and I can't
Python: any(line.startswith('#') for line in file)
English: Any line starts with "#" in the file?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev