Skip to content


Reset execution counter after cache is cleared #712

wants to merge 1 commit into from

2 participants


This is to prevent the counter from shooting up much above 1000 (the cache limit). If the counter is not reset, it keeps growing forever.

Please review this change carefully: I do not know if changing the execution counter has any other effect, and can simply verify that this brings the prompt back to 1 after clearing the cache (but I do believe this is the right thing to do, given that the cache is cleared out).

IPython: interactive computing in Python member

I don't think this is a good idea, unfortunately. The execution count is used to index lines in the input history, which doesn't get reset when this cache is flushed.

Conceptually, the prompt number is your position in your session, which isn't affected by the cache being flushed. I'd find it very offputting if it suddenly reset itself, because that implies that I'm starting with a fresh session. Looking at the file, we should probably reword the warning message that shows up when you reach the cache size.

In fact, I think there's a better solution than this. This system, without any prior warning, drops all but the last three items in history, which could be annoying if it happens at a critical moment. How about, on reaching the cache size, we drop the oldest ~20% of items from the cache, either silently or with a one-line message? This would mean that, by default, you always have at least the last 800 outputs available.


That sounds like a much more reasonable approach to cache handling.

The reason I "fixed" the execution count is because the notebook relies on that number not becoming much more than 3 digits. But, then again, how many people ever run 10,000 lines of execution in IPython (a notebook like that would be really, really slow to execute in full).

IPython: interactive computing in Python member

OK, I'll have a go at reworking the cache handling.

Hmmm, what's the issue in the notebook if the number exceeds three digits? Is that something we can fix? But I agree, it's unlikely that a notebook will get that long. I think the notebook model also lends itself to fewer, longer, multiline cells, and we should only need one number per cell.

I'm going to close this PR and open a new issue for the cache handling.

@takluyver takluyver closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Aug 20, 2011
  1. @stefanv
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 0 deletions.
  1. +2 −0 IPython/core/
2 IPython/core/
@@ -327,3 +327,5 @@ def flush(self):
# TODO: Is this really needed?
+ = 0
Something went wrong with that request. Please try again.