[IPython-dev] New ipythonqt console questions/feedback

MinRK benjaminrk at gmail.com
Wed Oct 6 17:30:37 EDT 2010

On Wed, Oct 6, 2010 at 13:37, Erik Tollerud <erik.tollerud at gmail.com> wrote:

> Thanks for the quick response!  I have a few responses in-line below
> (also a question about the issue tracker), but I also thought of one
> more thing that I was unclear about:
> As I understand it, the new 2-process model is in place to decouple
> the console from the execution kernel.  Given this, is there a
> straightforward way to close the ipythonqt terminal (or a standard
> ipython terminal) while leaving the execution kernel operating?  I was
> able to connect to the kernel with a second ipythonqt console, but
> don't see a way to disconnect the first terminal from the execution
> kernel without killing the execution kernel... Or is that conversion
> process for the parallel computing work that you said was still in
> progress? It seems like this is a valuable capability that would
> finally let me get away from using gnu screen whenever I want to be
> able to check in on a python process remotely (a common use-case for
> me)...

This is definitely doable with the underlying machinery; it's really a
matter of startup scripts.  There could easily be a script for starting
*just* an ipython kernel bound to no frontends, then start all frontends
just like you currently do with the second frontend. That script isn't
written yet, though. It would presumably be the new 'ipkernel' script.

For now, I whipped up an example which just adds a '--kernel-only' flag to
ipythonqt that skips the frontend setup:

> >> * Is it possible to execute the new-style ipython profiles when
> >> ipythonqt starts?  Looking at the ipythonqt main, it doesn't look to
> >> me like it's in there, but seems potentially pretty straightforward.
> >> This is the most crucial change for me as I have a lot of things that
> >> I want loaded by default (especially "from __future__ import division"
> >> !)
> >
> > Not yet, it's very high on the todo list.  We simply haven't
> > implemented *any* configurability yet, I'm afraid.
> Ok, I might take a crack at this if I have a chance - seems pretty
> straightforward.
> >> * If not, is it possible to tie ctrl-D to the exit() function?  I
> >> think a lot of people used to the python terminal expect ctrl-D to be
> >> available to quit the terminal, so it might be a nice option to add
> >> in.  Ideally, it would also just quit, skipping over the yes/no dialog
> >> that exit() triggers with an automatic yes.  I understand, though, if
> >> that is just to be too easy to accidentally do.
> >
> > Well, since the environment is now much more of a multiline editing
> > system, we made the keybindings mimic the Emacs ones, so C-D does
> > character delete.  I imagine it would be possilbe to see if it's at
> > the end of the buffer and trigger exit in that case, but I don't know
> > how easy that will be on the Qt side.
> Perhaps come other key combination might be easier (perhaps C-c is the
> next-most-natural choice?) - mainly I just want a single-keystroke way
> of exiting...

As soon as you have a standalone GUI that feels a terminal, exposing a
keybinding API becomes important.  We should probably ape someone else's
model for this, so as to minimize relearning for users. Do you have any
examples of nicely customizable apps for us to look at?

> >
> > As for confirmation, we definitely want to refine the exit code to
> > allow unconditional exiting.  My take on it is that exit from a close
> > window event should ask (an accidental mis-click can easily happen)
> > but exit from typing explicitly 'exit' should be unconditional (nobody
> > types a full word by accident).
> >
> > Would you mind making a ticket for this?  I think I know roughly how
> > to do it, but I don't have time for it right now.  I made a
> > 'qtconsole' label to apply to these tickets so we can sort them
> > easily.
> Done (ticket 161)... Although I can't figure out how to apply the
> "qtconsole" label to an issue - do I have to include it in the text of
> the issue somehow?  Or do I need some sort of elevated access
> privileges?

I think you need privileges for this.  I added the tag to 161,162.

> >
> >> * Unlike the terminal ipython, it seems that command history does not
> >> persist if I close out of ipythonqt and come back in.  Is this
> >> intentional?  I find it to be a highly useful feature...
> >
> > Please file a ticket so we don't forget this one also, it's important
> > and I miss it too.
> Done (ticket 162), although see my comment above about some confusion
> with the issue tracker.


> --
> Erik Tollerud
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101006/550ff307/attachment.html>

More information about the IPython-dev mailing list