Koos Zevenhoven 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 minimal maintenance b
Koos Zevenhoven 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 is "Raised when th
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.
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
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
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
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
arr
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 powerso
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
