GNU bug report logs - #18052
24.3; python.el and ipython shell

Previous Next

Full log

Message #27 received at 18052-done <at> debbugs.gnu.org (full text, mbox):

From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
To: Federico Beffa <beffa <at> ieee.org>
Cc: 18052-done <at> debbugs.gnu.org
Subject: Re: bug#18052: 24.3; python.el and ipython shell
Date: Sun, 20 Jul 2014 03:02:06 -0300

Federico Beffa <beffa <at> ieee.org> writes:

> Unfortunately it does not. I see the same intermittent problem as
> without the "-u" option.
>

So I tracked down what's going on.  Removing "console" from your
`python-shell-interpreter-args' should do the trick.

The "console" subcommand, starts an iPython server (AKA kernel) and then
connects the client console to it (that's the reason you see two
processes).  Removing the "console" subcommand just starts a standalone
iPython shell that doesn't suffer from this intermittent initialization
problem.

Now the reason why the console subcommand fails seems to be an iPython
bug itself.  What happens is that python.el shell setup codes are sent
quickly as soon as the inferior process starts, but it seems that
sometimes the iPython kernel startup doesn't expect that and fails to
start properly, thus causing the resulting iPython shell to be non
responsive.

This is not particularly a problem of python.el, in fact the issue can
be replicated in the commandline by spawning processes like so:

    echo "print ('yes')" | ipython console

With that, I get the same intermittent behavior observed previously.  So
my suggestion is to report this bug upstream.

In the meantime, I'll include some notes about this in the header of
python.el.


PS: As you may expect, when an iPython kernel is already started, using
"console --existing" works reliably, this may be useful in case you
really needed the client-server mode.



Cheers,
Fabián

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.