Skip to content
This repository

We should be less aggressive in de-registering post-execution functions #1154

Closed
fperez opened this Issue December 14, 2011 · 7 comments

2 participants

Fernando Perez Min RK
Fernando Perez
Owner

I'm marking this as a blocker so we make a decision on it in the next few days. If we decide to make a change, the implementation is easy.

Currently, if a post-execution function fails we immediately de-register it. The rationale for this was originally that if the user had a bad function, there was no point in failing every time.

But in more extensive use, I'm realizing this is a bad policy in practice. To see the issue, try in a pylab notebook just this one cell:

plt.title("Naïve")

note that this is unicode without the proper u qualifier. That triggers a matplotlib exception (as it should) but we immediately go ahead and disable further figure display:

Disabling failed post-execution function: <function flush_figures at 0x7fe574a20a28>
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (316, 0))

So even though in this case the user did pass invalid input, from this point on their experience will simply be "the notebook doesn't work anymore". They can recover functionality by calling %pylab which re-registers the figure display function, but most people will just be puzzled by the behavior and likely just do a full session restart (possibly losing costly computations).

I think what we should do instead is to store in a set all functions that have ever failed at this stage, and change the error message to something like:

Function <....> produced an error.  If this problem persists, you can disable all problematic post-execution functions by calling:

get_ipython().disable_failing_postfuncs()

The user can then make the call manually if they really need it. But in a case like this example, they would simply realize their mpl error, fix their call and be able to continue.

Min RK
Owner

I think that's fine to do, though I would actually consider it a bug that we allow user errors to raise an exception in our callback. It seems to me that post-execute functions should be extremely safe, given their relatively low-level position. Especially ones that we write ourselves.

Fernando Perez
Owner

Well, but in the example above, it's not really our callback that causes an error, the traceback comes from matplotlib itself. You can see it by typing the same thing in a plain ipython --pylab session. And if we masked all exceptions in our callback, it would make it much harder for users to sort out by themselves situations like this one: in this example, the mpl traceback is actually pretty informative:

...
  File "/home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib/text.py", line 985, in is_math_text
    if cbook.is_math_text(s):
  File "/home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib/cbook.py", line 1868, in is_math_text
    "matplotlib display text must have all code points < 128 or use Unicode strings")
ValueError: matplotlib display text must have all code points < 128 or use Unicode strings

and seeing that would immediately tell a user what's going on. That's why I think we should actually let exceptions of this kind bubble through, and just make it very easy/obvious for the user to disable a callback if it's really a buggy one.

Min RK
Owner

It's not that our callback caused an error, it's that our callback allowed a user error to raise in itself, rather than calling showtraceback(). In general, IPython does not allow user errors to raise in IPython calls, but here we are allowing exactly that.

I still think your idea is a sensible one.

Looking at the error output, I am reminded that we should put messages about side effects after tracebacks, not before. The end of a traceback is much more visible in interactive use than the beginning.

Fernando Perez
Owner

Ah yes, I misunderstood your original message then. We could certainly wrap those calls with a try/except showtraceback().

Fernando Perez
Owner

BTW, if you want to take a crack at this one, go for it; I have to clean up some materials for the p4s lecture this afternoon.

Min RK
Owner

PR #1155 makes both changes - post-exec functions are not unregistered on first failure, and user-errors do not raise in flush_figures(), instead calling showtraceback().

Fernando Perez
Owner

Great, thanks! I'll review it in a bit...

Fernando Perez fperez closed this in 2c683b7 December 14, 2011
Fernando Perez fperez referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.