bug#71440: Python Inferior Mode Can’t Recognize My Prompt

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

I set the ‘PYTHONSTARTUP’ environment variable to a file
whose content is

```python
import sys
sys.ps1, sys.ps2 = "\033[32m►\033[0m", "\033[32m▻\033[0m"
```

It works well if I start Python3 in my terminal (Windows
Terminal, windows11’s built-in app).

However, if I use it in Emacs:

1. open a Python file in Emacs
2. type ‘C-c C-p’ (run-python)
3. in the buffer visiting the Python file, type ‘C-c C-c’
   (python-shell-send-buffer)

Python will throw an error:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__PYTHON_EL_eval' is not defined
```

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> Date: Sat, 8 Jun 2024 16:29:40 +0000
> msip_labels: 
> 
> I set the ‘PYTHONSTARTUP’ environment variable to a file
> whose content is
> 
> ```python
> import sys
> sys.ps1, sys.ps2 = "\033[32m►\033[0m", "\033[32m▻\033[0m"
> ```
> 
> It works well if I start Python3 in my terminal (Windows
> Terminal, windows11’s built-in app).
> 
> However, if I use it in Emacs:
> 
> 1. open a Python file in Emacs
> 2. type ‘C-c C-p’ (run-python)
> 3. in the buffer visiting the Python file, type ‘C-c C-c’
>    (python-shell-send-buffer)
> 
> Python will throw an error:
> 
> ```
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name '__PYTHON_EL_eval' is not defined

I'm guessing that this is because that #x25ba and #x25bb Unicode
characters don't survive your system codepage (which Emacs uses to
communicate with inferior Python).  What are the values of
w32-ansi-code-page and w32-multibyte-code-page on your system?

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

w32-ansi-code-page: 65001
w32-multibyte-code-page: 0

BTW, I turned on 
“Beta: Use Unicode UTF-8 for worldwide language support”.

bug#71440: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 17:06:18 +0000
> msip_labels:
> 
> w32-ansi-code-page: 65001
> w32-multibyte-code-page: 0
> 
> BTW, I turned on 
> “Beta: Use Unicode UTF-8 for worldwide language support”.

I recommend against that.  Emacs on MS-Windows doesn't support UTF-8
well because Windows doesn't (yet).  Using UTF-8 on Windows as the
default encoding is very much not recommended, because most programs
you run from Emacs will not support that.

Your value of w32-ansi-code-page might be the reason for the problem.
Try disabling the beta feature and see if the problem goes away.

bug#71440: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

After I turned off UTF-8 and restart computer,
they change to:

    w32-ansi-code-page: 1252
    w32-multibyte-code-page: 0

But the problem still exists.

bug#71440: Re: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 17:46:35 +0000
> msip_labels:
> 
> After I turned off UTF-8 and restart computer,
> they change to:
> 
>     w32-ansi-code-page: 1252
>     w32-multibyte-code-page: 0
> 
> But the problem still exists.

Because your PYTHONSTARTUP file is encoded in UTF-8, right?

Anyway, codepage 1252 cannot encode these two characters, so I think
you cannot use this value of PS2 at all on Windows with Emacs.  Sorry.

But it's a good thing that you disabled UTF-8 by default in Emacs, it
could probably cause you other problems.

bug#71440: Re: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

> Because your PYTHONSTARTUP file is encoded in UTF-8, right?

Yes.

> Anyway, codepage 1252 cannot encode these two characters

Python inferior mode works well with

```python
import sys
sys.ps1, sys.ps2 = "►", "▻"
```

The problem came after I change PS to "\033[32m►\033[0m".
"\033[32m" and "\033[0m" color the prompt in terminal.

bug#71440: Re: Re: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 19:50:14 +0000
> 
> > Anyway, codepage 1252 cannot encode these two characters
> 
> Python inferior mode works well with
> 
> ```python
> import sys
> sys.ps1, sys.ps2 = "►", "▻"
> ```

I think you are lucky if it does work.

> The problem came after I change PS to "\033[32m►\033[0m".
> "\033[32m" and "\033[0m" color the prompt in terminal.

You expect that to show colors in Emacs as well?  If not, I suggest to
define PS1 and PS2 specially for the inferior Python.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

> You expect that to show colors in Emacs as well?

I don’t care about the color of Python’s prompt in Emacs,
because Emacs has its own color scheme which looks nice!

As long as Python Inferior Mode displays those two
characters (‘►’ and ‘▻’) correctly I’ll happy.

Actually it DOES - there’s no problem when I use Python 
Inferior Mode directly.

The problem occurs when I call ‘python-shell-send-buffer’
from a Python buffer, as mentioned in my original post:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71440#5>.

> I suggest to define PS1 and PS2 specially for the inferior Python.

I have to say that this is hard to implement cleanly.

I’ve tried:

    (setopt python-shell-interpreter-args "-i -c sys.ps1,sys.ps2='►▻'")

but it turned out that the ‘PYTHONSTARTUP’ file is loaded 
after the statement following ‘-c’ is executed.

______

I think this can be a feature request: provide an option 
to ignore any setting-color character sequence (eg `\033[32m`)
in XXYYZZ Inferior Mode, because there’re so many REPL
apps using a colored prompt and Emacs may not handle them
properly.

bug#71440: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> Date: Sun, 9 Jun 2024 10:11:29 +0000
> msip_labels:
> 
> The problem occurs when I call ‘python-shell-send-buffer’
> from a Python buffer, as mentioned in my original post:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71440#5>.

I know almost nothing about Python, but I wonder how PS1 and PS2 are
at all relevant when using python-shell-send-buffer?  That function
sends the buffer text to Python, so where do PS1 and PS2 come into
play, and why does Python say "__PYTHON_EL_eval is not defined" just
because you have PS1 and PS2 customized?

If someone helps me understand that, maybe I will have further ideas.

> > I suggest to define PS1 and PS2 specially for the inferior Python.
> 
> I have to say that this is hard to implement cleanly.
> 
> I’ve tried:
> 
>     (setopt python-shell-interpreter-args "-i -c sys.ps1,sys.ps2='►▻'")
> 
> but it turned out that the ‘PYTHONSTARTUP’ file is loaded 
> after the statement following ‘-c’ is executed.

How about defining PYTHONSTARTUP to point to a different file?

> I think this can be a feature request: provide an option 
> to ignore any setting-color character sequence (eg `\033[32m`)
> in XXYYZZ Inferior Mode, because there’re so many REPL
> apps using a colored prompt and Emacs may not handle them
> properly.

I'm not sure I even understand how the color settings are relevant to
python-shell-send-buffer.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

> I wonder how PS1 and PS2 are at all relevant when using 
> python-shell-send-buffer?  That function sends the buffer
> text to Python, so where do PS1 and PS2 come into play,
> and why does Python say "__PYTHON_EL_eval is not defined" 
> just because you have PS1 and PS2 customized?

I know it’s *weird* but it just happened.
I gave the recipes in the original post for anyone to 
reproduce it.

> If someone helps me understand that, maybe I will have 
> further ideas.

How about CC this post to the maintainer(s) of ‘python.el’?

> How about defining PYTHONSTARTUP to point to a different 
> file?

This makes it inconvenient to add or modify content to the 
‘PYTHONSTARTUP’ file because each change needs to be synced
to another file that exists for Emacs.

bug#71440: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> From: "shynur ." <one.last.kiss@outlook.com>
> CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> Date: Sun, 9 Jun 2024 10:49:19 +0000
> msip_labels:
> 
> > I wonder how PS1 and PS2 are at all relevant when using 
> > python-shell-send-buffer?  That function sends the buffer
> > text to Python, so where do PS1 and PS2 come into play,
> > and why does Python say "__PYTHON_EL_eval is not defined" 
> > just because you have PS1 and PS2 customized?
> 
> I know it’s *weird* but it just happened.
> I gave the recipes in the original post for anyone to 
> reproduce it.
> 
> > If someone helps me understand that, maybe I will have 
> > further ideas.
> 
> How about CC this post to the maintainer(s) of ‘python.el’?

Done.

> > How about defining PYTHONSTARTUP to point to a different 
> > file?
> 
> This makes it inconvenient to add or modify content to the 
> ‘PYTHONSTARTUP’ file because each change needs to be synced
> to another file that exists for Emacs.

You are on Windows, so some measure of inconvenience is expected.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[kobarity]

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

Eli Zaretskii wrote:
> 
> > From: "shynur ." <one.last.kiss@outlook.com>
> > CC: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> > Date: Sun, 9 Jun 2024 10:49:19 +0000
> > msip_labels:
> > 
> > > I wonder how PS1 and PS2 are at all relevant when using 
> > > python-shell-send-buffer?  That function sends the buffer
> > > text to Python, so where do PS1 and PS2 come into play,
> > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > just because you have PS1 and PS2 customized?
> > 
> > I know it’s *weird* but it just happened.
> > I gave the recipes in the original post for anyone to 
> > reproduce it.
> > 
> > > If someone helps me understand that, maybe I will have 
> > > further ideas.
> > 
> > How about CC this post to the maintainer(s) of ‘python.el’?
> 
> Done.
> 
> > > How about defining PYTHONSTARTUP to point to a different 
> > > file?
> > 
> > This makes it inconvenient to add or modify content to the 
> > ‘PYTHONSTARTUP’ file because each change needs to be synced
> > to another file that exists for Emacs.
> 
> You are on Windows, so some measure of inconvenience is expected.

Seems like a bug or limitation in `python-shell-prompt-detect'.  Can
you try the attached diff?  It should work with Python 2.6 or higher.

[-- Attachment #2: 71440.diff --]
[-- Type: application/octet-stream, Size: 1192 bytes --]

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index bb2bf1731b4..14e4ba1c6cc 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -3102,10 +3102,9 @@ python-shell-prompt-detect
   (when python-shell-prompt-detect-enabled
     (python-shell-with-environment
       (let* ((code (concat
-                    "import sys\n"
+                    "import json, sys\n"
                     "ps = [getattr(sys, 'ps%s' % i, '') for i in range(1,4)]\n"
-                    ;; JSON is built manually for compatibility
-                    "ps_json = '\\n[\"%s\", \"%s\", \"%s\"]\\n' % tuple(ps)\n"
+                    "ps_json = json.dumps(ps)\n"
                     "print (ps_json)\n"
                     "sys.exit(0)\n"))
              (interpreter python-shell-interpreter)
@@ -3168,7 +3167,7 @@ python-shell-prompt-detect
             "Or alternatively in:\n"
             "  + `python-shell-prompt-input-regexps'\n"
             "  + `python-shell-prompt-output-regexps'")))
-        prompts))))
+        (mapcar #'ansi-color-filter-apply prompts)))))
 
 (defun python-shell-prompt-validate-regexps ()
   "Validate all user provided regexps for prompts.

bug#71440: Python Inferior Mode Canʼt Recognize My Prompt

[shynur .]

> Can you try the attached diff?

Thank you very much!
It works perfectly this time, except there’s a

    Warning (python): Python shell prompts cannot be detected.
    
I’ve configured Emacs to ignore it.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[kobarity]

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

"shynur ." wrote:
> It works perfectly this time, except there’s a
>     Warning (python): Python shell prompts cannot be detected.

Thanks for testing.  Could you please try the improved patch I've
attached, which I believe will eliminate this warning as well?

> Eli Zaretskii wrote:
> > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > python-shell-send-buffer?  That function sends the buffer
> > > > text to Python, so where do PS1 and PS2 come into play,
> > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > just because you have PS1 and PS2 customized?

PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
execution completion.  The prompts must also be identified to
determine if the command can be sent.

Python REPL cannot accept the Python code as is.  For example, try
pasting the following code to the REPL:

if True:
    print("True")
print("Hi")

You should see the message "SyntaxError: invalid syntax".  This is
because the REPL requires an empty line to recognize the completion of
a block.  For such reasons, `python-shell-send-*' sends a string as
the argument to __PYTHON_EL_eval instead of sending the code as is.

__PYTHON_EL_eval is defined during the initialization of inferior
Python, but if the prompt is not recognized, its definition cannot be
done either.

The prompts are recognized by `python-shell-prompt-detect'.  A small
Python code sends PS1, etc. to Emacs as an array of JSON strings.
However, the JSON strings are hand-crafted for compatibility, as noted
in the comments below.

                    ;; JSON is built manually for compatibility

The json package was added in Python 2.6, so I assume it is to support
Python 2.5 and earlier.  This is fine for prompts consisting only of
ordinary characters, but will not result in a correct JSON string if
it contains escape sequences.

The attached improved patch uses the json package if available, so it
can handle escape sequences; without the json package, it works as
before.  It means that prompts containing escape sequences can be
recognized in Python 2.6 or later.  I have also added an ERT to check
this.

In the Inferior Python buffer, the escape sequences are removed using
`ansi-color-filter-apply'.  Therefore, I used the same function to
remove escape sequences at the end of `python-shell-prompt-detect' to
make the prompts match.

Another approach would be to remove the escape sequences on the Python
side.  It seems to be possible to do this using regular expressions,
but there does not seem to be a dedicated function for this.

[-- Attachment #2: 0001-Allow-escape-sequences-in-Python-prompts.patch --]
[-- Type: application/octet-stream, Size: 4161 bytes --]

From 3554c6d80134b6048f09b9c175c893968b8ddbc2 Mon Sep 17 00:00:00 2001
From: kobarity <kobarity@gmail.com>
Date: Wed, 12 Jun 2024 01:09:21 +0900
Subject: [PATCH] Allow escape sequences in Python prompts

* lisp/progmodes/python.el (python-shell-prompt-detect): Use
Python's json package if available, and remove escape sequences
in prompts.
* test/lisp/progmodes/python-tests.el
(python-tests-interpreter-2-6-higher-p): New predicate
function.
(python-shell-prompt-detect-7): New test.  (Bug#71440)
---
 lisp/progmodes/python.el            |  9 +++++++--
 test/lisp/progmodes/python-tests.el | 28 ++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 2664d71d358..ca5ecfab6ea 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -3104,8 +3104,13 @@ python-shell-prompt-detect
       (let* ((code (concat
                     "import sys\n"
                     "ps = [getattr(sys, 'ps%s' % i, '') for i in range(1,4)]\n"
+                    "try:\n"
+                    "    import json\n"
+                    "    ps_json = '\\n' + json.dumps(ps)\n"
+                    "except ImportError:\n"
                     ;; JSON is built manually for compatibility
-                    "ps_json = '\\n[\"%s\", \"%s\", \"%s\"]\\n' % tuple(ps)\n"
+                    "    ps_json = '\\n[\"%s\", \"%s\", \"%s\"]\\n' % tuple(ps)\n"
+                    "\n"
                     "print (ps_json)\n"
                     "sys.exit(0)\n"))
              (interpreter python-shell-interpreter)
@@ -3168,7 +3173,7 @@ python-shell-prompt-detect
             "Or alternatively in:\n"
             "  + `python-shell-prompt-input-regexps'\n"
             "  + `python-shell-prompt-output-regexps'")))
-        prompts))))
+        (mapcar #'ansi-color-filter-apply prompts)))))
 
 (defun python-shell-prompt-validate-regexps ()
   "Validate all user provided regexps for prompts.
diff --git a/test/lisp/progmodes/python-tests.el b/test/lisp/progmodes/python-tests.el
index ce103921454..04b9b448ec2 100644
--- a/test/lisp/progmodes/python-tests.el
+++ b/test/lisp/progmodes/python-tests.el
@@ -3820,6 +3820,17 @@ python-tests-interpreter-3-p
   (when (string= (car (split-string (cdr info) "\\.")) "3")
     (car info)))
 
+(defun python-tests-interpreter-2-6-higher-p (info)
+  "Check if the interpreter major version in INFO is 2.6 or higher.
+This function is intended to be used as the PRED argument of
+`python-tests-get-shell-interpreter'."
+  (let* ((version (split-string (cdr info) "\\."))
+         (major (string-to-number (car version)))
+         (minor (string-to-number (cadr version))))
+    (when (or (>= major 3)
+              (and (= major 2) (>= minor 6)))
+      (car info))))
+
 (ert-deftest python-shell-get-process-name-1 ()
   "Check process name calculation sans `buffer-file-name'."
   (python-tests-with-temp-buffer
@@ -4353,6 +4364,23 @@ python-shell-prompt-detect-6
            (should (not (get-buffer "*Warnings*"))))
        (ignore-errors (delete-file startup-file))))))
 
+(ert-deftest python-shell-prompt-detect-7 ()
+  "Check prompt autodetection with escape sequences.  Bug#71440."
+  (python-tests-with-shell-interpreter
+   #'python-tests-interpreter-2-6-higher-p
+   (let* ((process-environment process-environment)
+          (startup-code (concat "import sys\n"
+                                "sys.ps1 = '\033[32mpy> \033[0m'\n"
+                                "sys.ps2 = '\033[32m..> \033[0m'\n"
+                                "sys.ps3 = '\033[32mout \033[0m'\n"))
+          (startup-file (python-shell--save-temp-file startup-code)))
+     (unwind-protect
+         (progn
+           (setenv "PYTHONSTARTUP" startup-file)
+           (should python-shell-prompt-detect-enabled)
+           (should (equal (python-shell-prompt-detect) '("py> " "..> " "out "))))
+       (ignore-errors (delete-file startup-file))))))
+
 (ert-deftest python-shell-prompt-validate-regexps-1 ()
   "Check `python-shell-prompt-input-regexps' are validated."
   (let* ((python-shell-prompt-input-regexps '("\\("))
-- 
2.34.1

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> Date: Wed, 12 Jun 2024 01:24:39 +0900
> From: kobarity <kobarity@gmail.com>
> Cc: 71440@debbugs.gnu.org
> 
> 
> > Eli Zaretskii wrote:
> > > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > > python-shell-send-buffer?  That function sends the buffer
> > > > > text to Python, so where do PS1 and PS2 come into play,
> > > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > > just because you have PS1 and PS2 customized?
> 
> PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
> execution completion.  The prompts must also be identified to
> determine if the command can be sent.
> 
> Python REPL cannot accept the Python code as is.  For example, try
> pasting the following code to the REPL:
> 
> if True:
>     print("True")
> print("Hi")
> 
> You should see the message "SyntaxError: invalid syntax".  This is
> because the REPL requires an empty line to recognize the completion of
> a block.  For such reasons, `python-shell-send-*' sends a string as
> the argument to __PYTHON_EL_eval instead of sending the code as is.
> 
> __PYTHON_EL_eval is defined during the initialization of inferior
> Python, but if the prompt is not recognized, its definition cannot be
> done either.
> 
> The prompts are recognized by `python-shell-prompt-detect'.  A small
> Python code sends PS1, etc. to Emacs as an array of JSON strings.
> However, the JSON strings are hand-crafted for compatibility, as noted
> in the comments below.
> 
>                     ;; JSON is built manually for compatibility
> 
> The json package was added in Python 2.6, so I assume it is to support
> Python 2.5 and earlier.  This is fine for prompts consisting only of
> ordinary characters, but will not result in a correct JSON string if
> it contains escape sequences.
> 
> The attached improved patch uses the json package if available, so it
> can handle escape sequences; without the json package, it works as
> before.  It means that prompts containing escape sequences can be
> recognized in Python 2.6 or later.  I have also added an ERT to check
> this.

Thanks, but what do you mean by "json package" here?  Emacs nowadays
has JSON capabilities built in, so no optional features should be
required.  I did I misunderstand what you say above?

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[kobarity]

Eli Zaretskii wrote:
> 
> > Date: Wed, 12 Jun 2024 01:24:39 +0900
> > From: kobarity <kobarity@gmail.com>
> > Cc: 71440@debbugs.gnu.org
> > 
> > 
> > > Eli Zaretskii wrote:
> > > > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > > > python-shell-send-buffer?  That function sends the buffer
> > > > > > text to Python, so where do PS1 and PS2 come into play,
> > > > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > > > just because you have PS1 and PS2 customized?
> > 
> > PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
> > execution completion.  The prompts must also be identified to
> > determine if the command can be sent.
> > 
> > Python REPL cannot accept the Python code as is.  For example, try
> > pasting the following code to the REPL:
> > 
> > if True:
> >     print("True")
> > print("Hi")
> > 
> > You should see the message "SyntaxError: invalid syntax".  This is
> > because the REPL requires an empty line to recognize the completion of
> > a block.  For such reasons, `python-shell-send-*' sends a string as
> > the argument to __PYTHON_EL_eval instead of sending the code as is.
> > 
> > __PYTHON_EL_eval is defined during the initialization of inferior
> > Python, but if the prompt is not recognized, its definition cannot be
> > done either.
> > 
> > The prompts are recognized by `python-shell-prompt-detect'.  A small
> > Python code sends PS1, etc. to Emacs as an array of JSON strings.
> > However, the JSON strings are hand-crafted for compatibility, as noted
> > in the comments below.
> > 
> >                     ;; JSON is built manually for compatibility
> > 
> > The json package was added in Python 2.6, so I assume it is to support
> > Python 2.5 and earlier.  This is fine for prompts consisting only of
> > ordinary characters, but will not result in a correct JSON string if
> > it contains escape sequences.
> > 
> > The attached improved patch uses the json package if available, so it
> > can handle escape sequences; without the json package, it works as
> > before.  It means that prompts containing escape sequences can be
> > recognized in Python 2.6 or later.  I have also added an ERT to check
> > this.
> 
> Thanks, but what do you mean by "json package" here?  Emacs nowadays
> has JSON capabilities built in, so no optional features should be
> required.  I did I misunderstand what you say above?

I meant the json package of the Python standard library.  A small
Python code is embedded in python.el.  I changed this Python code to
use the json package of the Python standard library if available.

It may be easier to see the actual code:

      (let* ((code (concat
                    "import sys\n"
                    "ps = [getattr(sys, 'ps%s' % i, '') for i in range(1,4)]\n"
                    "try:\n"
                    "    import json\n"
                    "    ps_json = '\\n' + json.dumps(ps)\n"
                    "except ImportError:\n"
                    ;; JSON is built manually for compatibility
                    "    ps_json = '\\n[\"%s\", \"%s\", \"%s\"]\\n' % tuple(ps)\n"
                    "\n"
                    "print (ps_json)\n"
                    "sys.exit(0)\n"))

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[shynur .]

kobarity:
> Could you please try the improved patch I've attached,
> which I believe will eliminate this warning as well?

Thanks.  No error or warning now.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[kobarity]

shynur . wrote:
> 
> kobarity:
> > Could you please try the improved patch I've attached,
> > which I believe will eliminate this warning as well?
> 
> Thanks.  No error or warning now.

Thanks for confirming.  Unless I get feedback from others, this is the
final version from me.

bug#71440: Python Inferior Mode Can’t Recognize My Prompt

[Eli Zaretskii]

> Date: Thu, 13 Jun 2024 23:24:15 +0900
> From: kobarity <kobarity@gmail.com>
> Cc: "71440@debbugs.gnu.org" <71440@debbugs.gnu.org>
> 
> shynur . wrote:
> > 
> > kobarity:
> > > Could you please try the improved patch I've attached,
> > > which I believe will eliminate this warning as well?
> > 
> > Thanks.  No error or warning now.
> 
> Thanks for confirming.  Unless I get feedback from others, this is the
> final version from me.

Now installed on master, and closing the bug.

Thanks.