<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Oct 18, 2017 at 5:48 PM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><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="m_61493128504830026gmail-">On 18 October 2017 at 22:36, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@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"><span class="m_61493128504830026gmail-"><span class="m_61493128504830026gmail-m_-8910702207429755659gmail-"><div><font face="arial, helvetica, sans-serif">On Wed, Oct 18, 2017 at 2:08 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br></font></div></span></span><span class="m_61493128504830026gmail-"><div class="gmail_extra"><div class="gmail_quote"><span class="m_61493128504830026gmail-m_-8910702207429755659gmail-"><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"><div><font face="arial, helvetica, sans-serif">That one can only be fixed in count() - list already checks operator.length_hint(), so implementing itertools.count.__length_hint_<wbr>_() to always raise an exception would be enough to handle the container constructor case.<br></font></div></div></div></div></blockquote><div><br></div></span><div><div style="font-family:monospace,monospace">While that may be a convenient hack to solve some of the cases, maybe it's possible for list(..) etc. to give Ctrl-C a chance every now and then? (Without a noticeable performance penalty, that is.) That would also help with *finite* C-implemented iterables that are just slow to turn into a list. </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">If I'm not mistaken, we're talking about C-implemented functions that iterate over C-implemented iterators. It's not at all obvious to me that it's the iterator that should handle Ctrl-C.</div></div></div></div></span></div></blockquote><div><br></div><font face="arial, helvetica, sans-serif">It isn't, it's the loop's responsibility. The problem is that one of the core design assumptions in the CPython interpreter implementation is that signals from the operating system get handled by the opcode eval loop in the main thread, and Ctrl-C is one of those signals.</font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif">This is why "for x in itertools.cycle(): pass" can be interrupted, while "sum(itertools.cycle())" can't: in the latter case, the opcode eval loop isn't running, as we're inside a tight loop inside the sum() implementation.</font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif">It's easy to say "Well those loops should all be checking for signals then", but I expect folks wouldn't actually like the consequences of doing something about it, as:</font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif">1. It will make those loops slower, due to the extra overhead of checking for signals (even the opcode eval loop includes all sorts of tricks to avoid actually checking for new signals, since doing so is relatively slow)</font></div><div class="gmail_quote"><div class="gmail_quote"><font face="arial, helvetica, sans-serif">2. It will make those loops harder to maintain, since the high cost of
checking for signals means the existing flat loops will need to be
replaced with nested ones to reduce the per-iteration cost of the more expensive checks</font></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Combining points 1 and 2, I don't believe nesting loops is strictly a requirement.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></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"><div class="gmail_quote"><font face="arial, helvetica, sans-serif">3. It means making the signal checking even harder to reason about than it already is, since even C implemented methods that avoid invoking arbitrary Python code could now still end up checking for signals<br></font></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">So you're talking about code that would make a C-implemented Python iterable of strictly C-implemented Python objects and then pass this to something C-implemented like list(..) or sum(..), while expecting no Python code to be run or signals to be checked anywhere while doing it. I'm not really convinced that such code exists. But if such code does exist, it sounds like the code is heavily dependent on implementation details.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"> </span></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"><div class="gmail_quote"><font face="arial, helvetica, sans-serif"></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif">It's far from being clear to me that making such a change would actually be a net improvement, especially when there's an opportunity to mitigate the problem by having known-infinite iterators report themselves as such.<br></font></div><div class="gmail_quote"><font face="arial, helvetica, sans-serif"><br></font></div></div></div></div></blockquote><div><br></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">I'm not against that, per se. I just don't think that solves the quite typical case of *finite* but very tedious or memory-consuming loops that one might want to break out of. And raising an exception from .__length_hint__() might also break some obscure, but completely valid, operations on *infinite* iterables.</div><br></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><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"><div class="gmail_quote"><font face="arial, helvetica, sans-serif"></font></div>Cheers,</div></div><span class="m_61493128504830026gmail-"><div class="gmail_extra">Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="m_61493128504830026gmail-m_-8910702207429755659gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_61493128504830026gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>