Subject: bug#59477: python-tests fail without tree-sitter

From: kobarity <[email-masked]>
Date: Tue, 29 Nov 2022 00:18:10 +0900

Mattias Engdegård wrote:
> > 1. emacs -Q
> > 2. Open Python file. (Empty file is OK)
> > 3. C-c C-p (M-x run-python)
> > 4. C-x o (Back to the Python mode buffer)
> > 5. M-: (python-shell-send-string-no-output "print('a')")
> > 
> > My expectation is "a".
> 
> The result here is
> 
>  "__PYTHON_EL_eval(\"print('a')\", \"/Users/mattias/emacs/asdf.py\")\r\na"
> 
> which is consistent with the test failure -- something in python-mode is having trouble parsing the reply. I traced `python-shell-output-filter`; see attached file.
> 
> This might be bug#25753 again (via a comment in etc/PROBLEMS). Even if no effort is made to fix the bug properly, we should make sure the test doesn't fail.

Thank you for the logs and letting me know about bug#25753.  It seems
to be a bug that has existed for some time on Mac.  Here is the trace
on my Ubuntu.

======================================================================
1 -> (python-shell-output-filter ">>> ")
1 <- python-shell-output-filter: ""
======================================================================
1 -> (python-shell-output-filter ">>> ")
1 <- python-shell-output-filter: ""
======================================================================
1 -> (python-shell-output-filter "python.el: native completion setup loaded\n")
1 <- python-shell-output-filter: ""
======================================================================
1 -> (python-shell-output-filter ">>> ")
1 <- python-shell-output-filter: ""
======================================================================
1 -> (python-shell-output-filter "a\n")
1 <- python-shell-output-filter: ""
======================================================================
1 -> (python-shell-output-filter ">>> ")
1 <- python-shell-output-filter: ""

As for `python-ffap-module-path-1', it assumes that
`python-ffap-module-path' and its underlying
`python-shell-send-string-no-output' operate correctly.  So I think
the first option is to mark as an expected failure on Mac as the
attached patch.  However, I'm not sure if it fails on all Macs.
Another option may be to add :unstable tag.  Which do you think is
better?