On Sun, 15 Aug 2021 at 08:41, Andreas Röhler wrote: > On 14.08.21 11:29, Augusto Stoffel wrote: >> On Fri, 13 Aug 2021 at 18:44, Andreas Röhler 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.