<div dir="ltr"><div class="gmail_quote"><div>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.</div><div><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">On Sun, Jun 24, 2018 at 11:09 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Remember, the driving use-case which started this (ever-so-long) <br>
discussion was the ability to push data into a comprehension and then <br>
update it on each iteration, something like this:<br>
<br>
    x = initial_value()<br>
    results = [x := transform(x, i) for i in sequence]<br></blockquote><div><br></div><div>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.</div><div><br></div><div>    results = accumulate(sequence, transform)</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><div dir="ltr">On Fri, Jun 22, 2018 at 9:14 PM Chris Barker via Python-Dev <<a href="mailto:python-dev@python.org">python-dev@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">again, not a huge deal, just a little bit more complexity<br></div></div></div></blockquote><div><br></div><div>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.</div></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div dir="ltr">On Fri, Jun 22, 2018 at 7:48 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:<br><br>Of course they do -- they're less fluent at reading code. They don't <br>have the experience to judge good code from bad.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The question we should be asking is, do we only add features to Python <br>if they are easy for beginners? It's not that I especially want to add <br>features which *aren't* easy for beginners, but Python isn't Scratch and <br>"easy for beginners" should only be a peripheral concern.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mozilla's array comprehensions are almost identical to Python's, aside <br>from a couple of trivial differences:<br></blockquote><div><br></div><div>I can't prove it, but I think the phrase ordering difference is not trivial.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Students who are completely new to programming can see the similarity of<br>> [Python] list comprehensions to spoken language. <br><br>I've been using comprehensions for something like a decade, and I can't <br></blockquote><div><br></div><div>Python: any(line.startswith('#') for line in file)</div><div>English: Any line starts with "#" in the file?</div></div><div><br></div></div></div>