On Sun, Jun 24, 2018 at 4:57 PM Guido van Rossum <guido@python.org> wrote:
On Sun, Jun 24, 2018 at 2:41 PM Michael Selik <mike@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.

Absolutely. Since this has come up, I'll make an effort to be more systematic in data collection.

On Sun, Jun 24, 2018 at 11:09 AM Steven D'Aprano <steve@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 :-).

Mostly mid-career professionals, of highly varying backgrounds. The higher-order functions do require some cushioning getting into, but I have some tricks I've learned over the years to make it go over pretty well.

On Fri, Jun 22, 2018 at 7:48 PM Steven D'Aprano <steve@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.

By saying "Scratch for adults" I meant that Python is a language that can be adopted by beginners and rapidly make them professionals, not that it's exclusively a beginner's language.

Also, Scratch and similar languages, like NetLogo, have some interesting features that allow beginners to write some sophisticated parallelism. I don't mean "beginner's language" in that it's overly simplistic, but that it enables what would be complex in other languages.

I realize that my phrasing was likely to be misunderstood without knowing the context that I teach working professionals who are asked to be immediately productive at high-value tasks.