bug#49822: 28.0.50; python-shell-send functions show no output

[Augusto Stoffel <arstoffel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

On Sun, 15 Aug 2021 at 08:41, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> On 14.08.21 11:29, Augusto Stoffel wrote:
>> On Fri, 13 Aug 2021 at 18:44, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>>
>>> Hmm, a buffer is not an interactive shell. Putting a print() around
>>> should do it.
>> I'm not sure I get your point.  Evaluating an expression should print
>> the result, no?  It's the P in REPL.
>
> Python's interactive prompt offers a slightly different behavior than
> running code through a plain Python interpreter.
>
> I understand the code in a buffer as something which is executed as a
> program. If you run a program by a python interpreter, if it outputs 
> something, that depends.

Well, maybe that depends a bit on the use-case and taste.  But I would
like "send to the shell" to be more or less equivalent to "copy and
paste in the shell buffer".  Other people would prefer this as well,
cf. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29592

Anyway, I played around a bit and it's not hard to recover the Jupyter
behavior where evaluating some statements returns the last value.  The
attached file showing how it works.  I think Elpy does something
similar, in fact.

I'm struggling a bit on how this could be integrated with python.el.
Just dropping these new commands there would be easy, but not ideal; one
should probably integrate more tightly with the existing python-shell
commands, say by introducing a 'python-sell-echo-result' defcustom.  But
then I feel tempted to change various other things I don't like about
the Python shell, in particular the use of temporary files (as opposed
to escaped strings) to transfer pieces of code, which is very slow via
Tramp.

By the way, I also dislike how the 'python-shell-send-*' functions
don't even print a newline on the shell buffer, so that you see
    ">>> >>> >>>"
instead of
    ">>>\n>>>\n>>>"
after calling them thrice.  This means (1) a result may be printed right
next to the input prompt ">>>", and (2) it's impossible to tell if the
inferior process is busy by looking at the relative position of the
point and prompt.


[-- Attachment #2: python-shell-eval.el --]
[-- Type: application/emacs-lisp, Size: 2504 bytes --]