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

[fgallina@gnu.org (Fabián Ezequiel Gallina)]

Federico Beffa <beffa@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