Once again, I think Paul Moore gets to the heart of the issue.

Generators are simply confusing & async even more so.

Per my earlier email, the fact that generators look like functions, but are not functions, is at the root of the confusion.

This next part really gets to the heart of the matter:

On Sun, Oct 15, 2017 at 8:15 AM, Paul Moore <p.f.moore@gmail.com> wrote:
    To me, this implies that context variables should follow that
execution path. If the caller sets a value, the generator sees it. If
the generator sets a value then yields, the caller will see that. If
code changes the value between two resumptions of the generator, the
generator will see those changes. The PEP at this point, though,
states the behaviour of context variables in a way that I simply don't
follow - it's using the idea of an "outer context" - which as far as I
can see, has never been defined at this point

 This is the totally natural way to think of generators -- and exactly how I thought about them when I started -- and how I suspect 99% of beginners think of them:
  • And exactly what you expect since generators appear to be functions (since they use 'def' to create them).

Now, as I understand it, its not what really happens, in fact, they can have their own context, which the major discussion here is all about:

  1. Do we "bind" the context at the time you create the generator (which appears to call the generator, but really doesn't)?; OR
  2. Do we "bind" the context at the time the first .__next__ method is called?

And, as far as I can figure out, people are strongly arguing for #2 so it doesn't break backwards compatibility:

  • And then discussion of using wrappers to request #1 instead of #2

My answer is, you can't do #1 or #2 -- you need to do #3, as the default, -- what Paul write above -- anything else is "unnatural" and "non-intuitive".

Now, I fully understand we *actually* want the unnatural behavior of #1 & #2 in real code (and #3 is not really that useful in real code).

However #3 is the natural understanding of what it does ... so that what I am arguing needs to be implemented (as the default).

Then when we want either #1 or #2, when we are writing real code, -- there should be special syntax to indicate that is what we want (and yes, we'll have to use the special syntax 95%+ of the time since we really want #1 or #2 95%+ of the time; and don't want #3).

But that is the whole point, we *should* use special syntax to indicate we are doing something that is non-intuitive.

This special syntax helps beginners understand better & will help them think about the concepts more clearly (See previous post be me on adding first class language to defining generators, so its a lot clearer what is going on with then).

My argument, is a major strength of python, is how the syntax helps teach you concepts & how easy the language is to pick up.  I've talked to so many people who have said the same thing about the language when they started.

Generators (and this whole discussion of context variables) is not properly following that paradigm; and I believe it should.  It would make python even stronger as a programming language of choice, that not only is easy to use, but easy to learn from as you start programming.