Skip to content


Subversion checkout URL

You can clone with
Download ZIP


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

dwf opened this Issue · 5 comments

3 participants

dwf commented

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.


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/

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 commented

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.


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 commented

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.


This was closed by PR #339

@minrk minrk closed this
@damianavila damianavila referenced this issue from a commit
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.