exit( and quit( in Qt console produces phantom signature/docstring popup, even though quit() or exit() raises NameError #337

Closed
dwf opened this Issue Apr 8, 2011 · 5 comments

Comments

Projects
None yet
3 participants
@dwf
Contributor

dwf commented Apr 8, 2011

A very minor oddity I noticed in master while running the (very impressive) Qt console. Title pretty much says it all. Being unfamiliar I typed "quit(" (which is how I usually quit on the ancient IPython 0.8.3 installed at the lab) and was given an incorrect information about its call signature (but told it had no docstring). Attempting to call either raises a NameError.

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Apr 8, 2011

Owner

Two issues there. At a guess, the tooltip is popping up because the information request is being handled without the modification to the builtins that we make for execution (see IPython/core/builtin_trap.py).

As for calling either: we override exit and quit with magic commands, so you can just type exit. It would be good to do something more helpful if you try to call a magic command (exit()) though.

Owner

takluyver commented Apr 8, 2011

Two issues there. At a guess, the tooltip is popping up because the information request is being handled without the modification to the builtins that we make for execution (see IPython/core/builtin_trap.py).

As for calling either: we override exit and quit with magic commands, so you can just type exit. It would be good to do something more helpful if you try to call a magic command (exit()) though.

@dwf

This comment has been minimized.

Show comment Hide comment
@dwf

dwf Apr 8, 2011

Contributor

Yep, I figured that last part out. I guess in general it would be good to detect collisions between builtins and magics that shadow them if you try to call them, but giving the user false information via incorrect call tips is probably of more immediate concern. :)

I'm not sure of the right place to it though. I think I've got a pretty good idea of what's going on (client passes object_info message and replies with the result of object_inspect from InteractiveShell), but there doesn't seem to be a "right" place to deal with this magic corner case.

It seems that what needs to happen is either that first message has to carry back some information with it (specifically whether the shell instance is in automagic mode and has a magic attribute that shadows a builtin with that name, etc.), or there needs to be a more messages exchanged. I am sufficiently ignorant of the design philosophy you guys have taken to know exactly what the right approach is, though.

Contributor

dwf commented Apr 8, 2011

Yep, I figured that last part out. I guess in general it would be good to detect collisions between builtins and magics that shadow them if you try to call them, but giving the user false information via incorrect call tips is probably of more immediate concern. :)

I'm not sure of the right place to it though. I think I've got a pretty good idea of what's going on (client passes object_info message and replies with the result of object_inspect from InteractiveShell), but there doesn't seem to be a "right" place to deal with this magic corner case.

It seems that what needs to happen is either that first message has to carry back some information with it (specifically whether the shell instance is in automagic mode and has a magic attribute that shadows a builtin with that name, etc.), or there needs to be a more messages exchanged. I am sufficiently ignorant of the design philosophy you guys have taken to know exactly what the right approach is, though.

@takluyver

This comment has been minimized.

Show comment Hide comment
@takluyver

takluyver Apr 8, 2011

Owner

Automagics are, I believe, on or off at the kernel level, so we don't need any more info for that. I think we just need ensure that object_info requests are handled inside the builtin_trap context manager; that way it won't find the builtin exit or quit functions. But the kernel-client model isn't something I've worked on a lot.

Owner

takluyver commented Apr 8, 2011

Automagics are, I believe, on or off at the kernel level, so we don't need any more info for that. I think we just need ensure that object_info requests are handled inside the builtin_trap context manager; that way it won't find the builtin exit or quit functions. But the kernel-client model isn't something I've worked on a lot.

@dwf

This comment has been minimized.

Show comment Hide comment
@dwf

dwf Apr 8, 2011

Contributor

You're right. I'm just sufficiently unfamiliar with context managers that I didn't see that as an obvious solution. :) I've submitted a pull request.

Contributor

dwf commented Apr 8, 2011

You're right. I'm just sufficiently unfamiliar with context managers that I didn't see that as an obvious solution. :) I've submitted a pull request.

@minrk

This comment has been minimized.

Show comment Hide comment
@minrk

minrk Apr 8, 2011

Owner

This was closed by PR #339

Owner

minrk commented Apr 8, 2011

This was closed by PR #339

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment