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

[kobarity <kobarity@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]


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?


[-- Attachment #2: 0001-Mark-python-ffap-module-path-1-as-an-expected-failur.patch --]
[-- Type: application/octet-stream, Size: 945 bytes --]

From b560b9744d6db7d0107a16699c95c91a7a4d6efc Mon Sep 17 00:00:00 2001
From: kobarity <kobarity@gmail.com>
Date: Tue, 29 Nov 2022 00:05:23 +0900
Subject: [PATCH] Mark python-ffap-module-path-1 as an expected failure on Mac

* test/lisp/progmodes/python-tests.el (python-ffap-module-path-1):
Mark as an expected failure on Mac. (Bug#59477)
---
 test/lisp/progmodes/python-tests.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
index f871b7bc7d..2bfaa33634 100644
--- a/test/lisp/progmodes/python-tests.el
+++ b/test/lisp/progmodes/python-tests.el
@@ -4565,6 +4565,7 @@ python-completion-at-point-native-with-eldoc-1
 ;;; FFAP
 
 (ert-deftest python-ffap-module-path-1 ()
+  :expected-result (if (eq system-type 'darwin) :failed :passed)
   (skip-unless (executable-find python-tests-shell-interpreter))
   (python-tests-with-temp-buffer-with-shell
    "
-- 
2.34.1