bug#49073: 28.0.50; python-send-to-repl functions misbehave

[dalanicolai]

Thanks for the update! Unfortunately, I actually rarely code in python. It was
just when I did for a moment, then I noticed this surprising behavior of the
'python-send-repl' functions (which turned out to be partly a Spacemacs issue,
and partly fixed already through the extra flag for (not) sending the coding
cookie).

About the first 'bug' (showing the input), I was considering the ipython shell
where one can refer to previous input by its number. But I agree that for
send-to-repl functions printing the input is not a very useful addition.

Looking at the description of the patch, the new behavior looks preferable to me
as it is generally nice to see some values when sending statements/code during
interactive development.

On Sat, 28 Aug 2021 at 11:43, Augusto Stoffel <arstoffel@gmail.com> wrote:

On Thu, 17 Jun 2021 at 16:53, dalanicolai@gmail.com wrote:

> This is a combined bug report for two unrelated but still somewhat
> related bugs.
>
> - The first bug is that when using `python-send-to-repl` functions, the
>   input does not get printed in the REPL buffer.
> - The second bug is that for various setups, even the output does not
>   get printed properly.
>

See the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49822#45
for a proposed solution to the second problem.

As to the first problem (not echoing the input): I think this would be
pretty hard to implement in a dumb terminal.  You could try running the
Python shell in a terminal emulator (term or vterm) and write a macro to
paste regions of text into it.  In any case, echoing the input also
seems to be a somewhat unconventional behavior.  I don't think I would
want that.

PS: By 'python-send-to-repl' I assume you mean the 'python-shell-send-*'
family of commands, or do you refer to some external package?