On Thu, 26 Aug 2021 at 16:09, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> If you could fix this (i.e., not use temporary files), that would be
> very nice.

All right, I'm attaching a proposal for 'python-shell-send-string'
(affecting also all other 'python-shell-send-' functions except
'python-shell-send-buffer').

The main user-visible change is that now a result is printed in the
shell in all possible cases, i.e.:

1. If the string being evaluated is a one-line expression.
2. If the string being evaluated is a multiline expression such as
   "(1+\n1)".
3. The string being evaluated is contains multiple statements, the last
   of which is an expression.  E.g., "x=1\nx".

Currently, only case 1 prints a result (this is the actual topic of this
bug).

By avoiding to use 'python-shell-send-file', the following additional
issues are fixed:

1. The plumbing code used to execute the user's code could crop up in a
   stack trace (Bug#32042).  This is now almost completely fixed (the
   only exception I see is in the plain python3 interpreter, where a
   not-too-annoying mention to __PYTHON_EL_eval still appears.)
2. Sending temporary files over Tramp has a noticeable delay (and lots
   of echo area messages).  In particular, completion is now faster on
   remote Python shells.
3. Some global symbols (os, codecs, etc.) used to be redefined; some
   others (compile, etc.) used to be assumed to not have been redefined
   by the user.  We now only assume this is the case for 'exec' (because
   it's a keyword in Python 2).

Note, however, that 'python-shell-send-file' remains unchanged.

This is a reasonably sensitive change and it would be good to collect
feedback from others before merging it (a properly formatted patch will
then follow).  In particular, since I'm not an expert in Python's
internals, there might be some possible refinements to the
__PYTHON_EL_eval function.  Is this perhaps a better topic for the
emacs-devel list?