Skip to content
This repository

Exception hook should be optional for embedding IPython in GUIs #54

Closed
ipython opened this Issue May 10, 2010 · 9 comments

4 participants

IPython: interactive computing in Python Fernando Perez Min RK Thomas Kluyver
IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

Original Launchpad bug 337105: https://bugs.launchpad.net/ipython/+bug/337105
Reported by: gael-varoquaux (Gael Varoquaux).

When embbeding IPython, the exception hook (IPython crashed.... ) captures exception that are not IPython exceptions. It can be desirable not to capture any exceptions and to let the application designer deal with the exceptions.

As such, it would be nice if the main exception hook could be disabled by a switch on the IPython0 instance.

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 1 by: Ville M. Vainio, on 2009-03-03 08:28:03+00:00 ]

On Tue, Mar 3, 2009 at 10:19 AM, Gael Varoquaux
gael.varoquaux@normalesup.org wrote:

Public bug reported:

When embbeding IPython, the exception hook (IPython crashed.... )
captures exception that are not IPython exceptions. It can be desirable
not to capture any exceptions and to let the application designer deal
with the exceptions.

As such, it would be nice if the main exception hook could be disabled
by a switch on the IPython0 instance.

I accomplish this in qt ui by:

cruel hack to avoid subclassing and prevent crash handler

IPython.iplib.InteractiveShell.isThreaded = True

Ville M. Vainio
http://tinyurl.com/vainio

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 2 by: Gael Varoquaux, on 2009-03-03 08:36:24+00:00 ]

On Tue, Mar 03, 2009 at 08:28:03AM -0000, Ville M. Vainio wrote:

On Tue, Mar 3, 2009 at 10:19 AM, Gael Varoquaux
gael.varoquaux@normalesup.org wrote:

Public bug reported:

When embbeding IPython, the exception hook (IPython crashed.... )
captures exception that are not IPython exceptions. It can be desirable
not to capture any exceptions and to let the application designer deal
with the exceptions.

As such, it would be nice if the main exception hook could be disabled
by a switch on the IPython0 instance.

I accomplish this in qt ui by:

cruel hack to avoid subclassing and prevent crash handler

IPython.iplib.InteractiveShell.isThreaded = True

OK, that will do the trick. I believe we can close this bug report.

Thanks,

Gaël

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 3 by: Fernando Perez, on 2009-03-14 12:52:18.557512+00:00 ]

Closing as won't fix since the solution is more of a workaround. As we refactor things, we can offer later a nicer way to do this. But I'm happy to close for now.

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 4 by: Gael Varoquaux, on 2009-03-15 12:27:02+00:00 ]

On Sat, Mar 14, 2009 at 12:52:18PM -0000, Fernando Perez wrote:

Closing as won't fix since the solution is more of a workaround. As we
refactor things, we can offer later a nicer way to do this. But I'm
happy to close for now.

** Changed in: ipython
Status: New => Won't Fix

I have just implemented this in the Enthought codebase (will move it up
to the frontend code in IPython soon).

This is simply horrible: module-level monkey patching. In other words:
huge side effects. I don't think this solution is acceptabe, and I'd like
this bug reopened, admitedly with a milestone set for later than 0.10.

The IPython-related code in ETS is full of similar hacks (like
monkey-patching raw_input). It renders the whole applications fragiles.

Gaël

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 5 by: Ville M. Vainio, on 2009-03-15 12:42:19+00:00 ]

On Sun, Mar 15, 2009 at 2:27 PM, Gael Varoquaux
gael.varoquaux@normalesup.org wrote:

This is simply horrible: module-level monkey patching. In other words:
huge side effects. I don't think this solution is acceptabe, and I'd like
this bug reopened, admitedly with a milestone set for later than 0.10.

I agree that it's horrible. A proper solution would be to implement
the crash handler as a hook (and have current crash handler as the
default handler if hook raises TryNext).

Ville M. Vainio
http://tinyurl.com/vainio

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 6 by: Gael Varoquaux, on 2009-03-15 13:40:03+00:00 ]

On Sun, Mar 15, 2009 at 12:42:19PM -0000, Ville M. Vainio wrote:

On Sun, Mar 15, 2009 at 2:27 PM, Gael Varoquaux
gael.varoquaux@normalesup.org wrote:

This is simply horrible: module-level monkey patching. In other words:
huge side effects. I don't think this solution is acceptabe, and I'd like
this bug reopened, admitedly with a milestone set for later than 0.10.

I agree that it's horrible. A proper solution would be to implement
the crash handler as a hook (and have current crash handler as the
default handler if hook raises TryNext).

That sounds good.

Gaël

IPython: interactive computing in Python
Owner
ipython commented May 10, 2010

[ LP comment 7 by: Fernando Perez, on 2009-03-15 20:58:59.289438+00:00 ]

Reopened as per feedback in thread. We'll look into it post-0.10 though.

Thomas Kluyver
Collaborator

Can someone confirm whether this is still an issue in trunk?

Min RK minrk closed this November 09, 2011
Min RK
Owner

The crash handler is attached to the Application object, not the InteractiveShell, so this shouldn't be an issue anymore. If an IPython Application is not initialized, the crash handler is never constructed.

For instance, the following code just gets a regular traceback:

from IPython.frontend.terminal.interactiveshell import TerminalInteractiveShell

class BadInteractiveShell(TerminalInteractiveShell):

    def run_cell(self, *args, **kwargs):
        TerminalInteractiveShell.run_cell(self, *args, **kwargs)
        1/0

BadInteractiveShell().mainloop()
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.