[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18052: 24.3; python.el and ipython shell

From: Fabián Ezequiel Gallina
Subject: bug#18052: 24.3; python.el and ipython shell
Date: Sun, 20 Jul 2014 03:02:06 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Federico Beffa <address@hidden> 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

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]