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?
>