On Wed, Oct 18, 2017 at 2:08 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 October 2017 at 20:39, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Oct 18, 2017 13:29, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 18 October 2017 at 19:56, Koos Zevenhoven <k7hoven@gmail.com> wrote:
I'm unable to reproduce the "uninterruptible with Ctrl-C"​ problem with infinite iterators. At least itertools doesn't seem to have it:

>>> import itertools
>>> for i in itertools.count():
...     pass
... 

That's interrupting the for loop, not the iterator. This is the test case you want for the problem Jason raised:

    >>> "a" in itertools.count()

Be prepared to suspend and terminate the affected process, because Ctrl-C isn't going to help :)

I'm writing from my phone now, cause I was dumb enough to try list(count())

Yeah, that's pretty much the worst case example, since the machine starts thrashing memory long before it actually gives up and starts denying the allocation requests :(
 
But should it be fixed in list or in count?

That one can only be fixed in count() - list already checks operator.length_hint(), so implementing itertools.count.__length_hint__() to always raise an exception would be enough to handle the container constructor case.


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. 

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.

––Koos


--
+ Koos Zevenhoven + http://twitter.com/k7hoven +