<div dir="ltr"><div class="gmail_extra">Once again, I think Paul Moore gets to the heart of the issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Generators are simply confusing & async even more so.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Per my earlier email, the fact that generators look like functions, but are not functions, is at the root of the confusion.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This next part really gets to the heart of the matter:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 15, 2017 at 8:15 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    To me, this implies that context variables should follow that<br>
execution path. If the caller sets a value, the generator sees it. If<br>
the generator sets a value then yields, the caller will see that. If<br>
code changes the value between two resumptions of the generator, the<br>
generator will see those changes. The PEP at this point, though,<br>
states the behaviour of context variables in a way that I simply don't<br>
follow - it's using the idea of an "outer context" - which as far as I<br>
can see, has never been defined at this point <br></blockquote><div><br></div><div> 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:<br></div><div><ul><li>And exactly what you expect since generators appear to be functions (since they use 'def' to create them).</li></ul><p>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:</p><ol><li>Do we "bind" the context at the time you create the generator (which appears to call the generator, but really doesn't)?; OR</li><li>Do we "bind" the context at the time the first .__next__ method is called?</li></ol><p>And, as far as I can figure out, people are strongly arguing for #2 so it doesn't break backwards compatibility:</p><ul><li> And then discussion of using wrappers to request #1 instead of #2<br></li></ul><p>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".<br></p><p>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).</p><p>However #3 is the natural understanding of what it does ... so that what I am arguing needs to be implemented (as the default).</p><p>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).</p><p>But that is the whole point, we *should* use special syntax to indicate we are doing something that is non-intuitive.</p><p>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).</p><p>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.<br></p><p>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.<br></p></div></div></div></div>