<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 10, 2017 at 5:34 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><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"><span class="gmail-">On 10 October 2017 at 01:24, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br></span><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"><span class="gmail-m_-5884825314232941533gmail-"><span class="gmail-">On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br></span><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"><span><span class="gmail-">On 8 October 2017 at 08:40, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<br></span><span class="gmail-"><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"><span class="gmail-m_-5884825314232941533gmail-m_920119363741997834m_6930246526210895346gmail-"></span><span class="gmail-m_-5884825314232941533gmail-m_920119363741997834m_6930246526210895346gmail-"></span><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:monospace,monospace">I do remember Yury mentioning that the first draft of PEP 550 captured something when the generator function was called. I think I started reading the discussions after that had already been removed, so I don't know exactly what it was. But I doubt that it was *exactly* the above, because PEP 550 uses set and get operations instead of "assignment contexts" like PEP 555 (this one) does. </div></div></div></div></div></blockquote><div><br></div></span></span><span class="gmail-"><div>We didn't forget it, we just don't think it's very useful.<br clear="all"></div></span></div></div></div></blockquote><div><br></div></span><span class="gmail-"><div>I'm not sure I agree on the usefulness. Certainly a lot of the complexity of PEP 550 exists just to cater to Nathaniel's desire to influence what a generator sees via the context of the send()/next() call. I'm still not sure that's worth it. In 550 v1 there's no need for chained lookups.<br></div></span></div></div></div></blockquote><div><br></div>The compatibility concern is that we want developers of existing libraries to be able to transparently switch from using thread local storage to context local storage, and the way thread locals interact with generators means that decimal (et al) currently use the thread local state at the time when next() is called, *not* when the generator is created.</div></div></div></blockquote><div><br></div><div>Apart from the example in PEP 550, is that really a known idiom?<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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I like Yury's example for this, which is that the following two examples are currently semantically equivalent, and we want to preserve that equivalence:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"> with decimal.localcontext() as ctx:</div><div class="gmail_quote"> ctc.prex = 30<br></div><div class="gmail_quote"><span class="gmail-"> for i in gen():<br>
pass<br>
<br></span> g = gen()<br><div class="gmail_quote"> with decimal.localcontext() as ctx:</div><div class="gmail_quote"> ctc.prex = 30<br></div><span class="gmail-"> for i in g:<br>
pass</span></div></div></div></blockquote><div><br></div><div>Do we really want that equivalence? It goes against the equivalence from Koos' example.<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"><div dir="ltr"><div class="gmail_extra">The easiest way to maintain that equivalence is to say that even though preventing state changes leaking *out* of generators is considered a desirable change, we see preventing them leaking *in* as a gratuitous backwards compatibility break.</div></div></blockquote><div><br></div><div>I dunno, I think them leaking in in the first place is a dubious feature, and I'm not too excited that the design of the way forward should bend over backwards to be compatible here.</div><div><br></div><div>The only real use case I've seen so far (not counting examples that just show how it works) is Nathaniel's timeout example (<span class="gmail-author-d-16z86ztz122z98z81zz82zz85zunv3z82zpqfnlaklz69zehdlvnz73zz65zz81zz79zz73zpz76z22z66ztsz89zz122zz73zz122zfz83z">see point 9 in </span><span class="gmail-attrlink gmail-url gmail-author-d-16z86ztz122z98z81zz82zz85zunv3z82zpqfnlaklz69zehdlvnz73zz65zz81zz79zz73zpz76z22z66ztsz89zz122zz73zz122zfz83z"><a target="_blank" class="gmail-attrlink" href="https://mail.python.org/pipermail/python-ideas/2017-August/046736.html" rel="noreferrer nofollow noopener">Nathaniel’s message</a>), and I'm still not convinced that that example is important enough to support either.</span></div><div><span class="gmail-attrlink gmail-url gmail-author-d-16z86ztz122z98z81zz82zz85zunv3z82zpqfnlaklz69zehdlvnz73zz65zz81zz79zz73zpz76z22z66ztsz89zz122zz73zz122zfz83z"><br></span></div><div><span class="gmail-attrlink gmail-url gmail-author-d-16z86ztz122z98z81zz82zz85zunv3z82zpqfnlaklz69zehdlvnz73zz65zz81zz79zz73zpz76z22z66ztsz89zz122zz73zz122zfz83z">It would all be easier to decide if there were use cases that were less far-fetched, or if the far-fetched use cases would be supportable with a small tweak. As it is, it seems that we could live in a simpler, happier world if we gave up on context values leaking in via next() etc. (I still claim that in that case we wouldn't need chained lookup in the exposed semantics, just fast copying of contexts.)<br></span></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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">This
does mean that *neither* form is semantically equivalent to eager extraction of the generator values before the decimal context is
changed, but that's the status quo, and we don't have a compelling
justification for changing it.<br></div></div></div></blockquote><div><br></div><div>I think the justification is that we could have a *significantly* simpler semantics and implementation.<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"><div dir="ltr"><div class="gmail_extra">If folks subsequently decide that they *do* want "capture on creation" or "capture on first iteration" semantics for their generators, those are easy enough to add as wrappers on top of the initial thread-local-compatible base by using the same building blocks as are being added to help event loops manage context snapshots for coroutine execution.<br></div><span class="gmail-"></span></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">(BTW Capture on first iteration sounds just awful.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think we really need to do more soul-searching before we decide that a much more complex semantics and implementation is worth it to maintain backwards compatibility for leaking in via next().<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>