<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 October 2017 at 22:51, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@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"><span class="gmail-"></span><div class="gmail_extra"><div style="font-family:monospace,monospace">I see no reason why these two should be equivalent.</div></div></div></blockquote><div><br></div>There is no "should" about it: it's a brute fact that the two forms *are* currently equivalent for lazy iterators (including generators), and both different from the form that uses eager evaluation of the values before the context change.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Where should enters into the picture is by way of PEP 550 saying that they should *remain* equivalent because we don't have an adequately compelling justification for changing the runtime semantics.</div><div class="gmail_quote"><br></div><div class="gmail_quote">That is, given the following code:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><span class="gmail-im"> itr = make_iter()<br><div class="gmail_quote"> with decimal.localcontext() as ctx:</div><div class="gmail_quote"> ctc.prex = 30<br></div><span class="gmail-m_-2088292188506436253gmail-"> for i in itr:<br>
pass</span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-"><br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-">Right now, today, in 3.6. the calculations in the iterator will use the modified decimal context, *not* the context that applied when the iterator was created. If you want to ensure that isn't the case, you have to force eager evaluation before the context change.<br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-"><br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-">What PEP 550 is proposing is that, by default, *nothing changes*: the lazy iteration in the above will continue to use the updated decimal context by default.</span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-"><br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-">However, people *will* gain a new option for avoiding that: instead of forcing eager evaluation, they'll be able to capture the creation context instead, and switching back to that each time the iterator needs to calculate a new value.<br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-"><br></span></span></div><div class="gmail_quote"><span class="gmail-im"><span class="gmail-m_-2088292188506436253gmail-">If PEP 555 proposes that we should instead make lazy iteration match eager evaluation semantics by *default*, then that's going to be a much harder case to make because it's a gratuitous compatibility break - code that currently works one way will suddenly start doing something different, and end users will have difficulty getting it to behave the same way on 3.7 as it does on earlier versions.<br></span></span></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br clear="all"></div><br>-- <br><div class="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></div>