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

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

Comments

Projects
None yet
4 participants
@ghost
Collaborator

ghost 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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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

Collaborator

ghost 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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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

Collaborator

ghost 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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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.

Collaborator

ghost 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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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

Collaborator

ghost 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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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

Collaborator

ghost 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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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

Collaborator

ghost 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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2010

Collaborator

[ 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.

Collaborator

ghost 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.

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 23, 2011

Member

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

Member

takluyver commented Mar 23, 2011

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

@ghost ghost assigned fperez Apr 10, 2011

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 10, 2011

Member

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()
Member

minrk commented Nov 10, 2011

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