[issue31815] Make itertools iterators interruptible

Koos Zevenhoven <k7ho...@gmail.com> added the comment: To repeat one of my points in the linked threads, I'm not convinced that infinite iterators are the most common case for the problem of long uninterruptible loops. A general mechanism that can be easily used in many places with m

[issue31815] Make itertools iterators interruptible

Koos Zevenhoven <k7ho...@gmail.com> added the comment: For the interactive user who uses an interactive environment such as the repl or a Jupyter notebook, the situation is a little different from "CPython as programming language runtime". The docs say a KeyboardInterrupt

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Koos Zevenhoven added the comment: I'd say there are three different problems related to this: (1) The inability of infinite iterators/iterables to say anything about their length (2) The inability to interrupt C-level loops (3) The horrible consequences of things like list(itertools.count

[issue34561] Replace list sorting merge_collapse()?

Koos Zevenhoven added the comment: It doesn’t seem like there’s a real problem here, but you seem to suggest there would be some useful improvements possible here. I don’t know much about sorting algorithms per se. What do you mean by galloping? -- nosy: +koos.zevenhoven

[issue34561] Replace list sorting merge_collapse()?

Koos Zevenhoven added the comment: Haha ok. Cache optimization makes it pretty complicated to reason about true costs. Anyway, it’s not obvious to me even that the run lengths would need to be descending for best performace. I’m not even starting to think about how the merging order might

[issue34561] Replace list sorting merge_collapse()?

Koos Zevenhoven added the comment: Sorry, I meant that the funny code in the "power" computation in powersort is a logarithmic measure. But I don't know where that came from. I just looked at Timsort and now figuring out how powersort is

[issue34561] Replace list sorting merge_collapse()?

Koos Zevenhoven added the comment: And by "looking at" Timsort, I mean reading your explanation. The motivation for merge ordering and so on was already quite clear from there. But that motivation does not imply that the stack has to be monotonous in run length, altho

[issue34561] Replace list sorting merge_collapse()?

Koos Zevenhoven added the comment: So it looks like we're working with a logarithmic measure of the "cost". I'm operating largely based on your description of Timsort in the link in msg324597, which the paper also refers to. But since the paper is sorting an array of

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Koos Zevenhoven added the comment: That said, I agree with Antoine that being able to Ctrl-C would be the most useful of these fixes. But it seems clear that people are experiencing these issues differently (if at all). -- ___ Python tracker