Eli Zaretskii wrote: > > > From: Liu Hui > > Date: Fri, 18 Jul 2025 23:31:50 +0800 > > Cc: michael.albinus@gmx.de, kobarity@gmail.com, 79036@debbugs.gnu.org > > > > On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii wrote: > > > > > > > From: Liu Hui > > > > Date: Fri, 18 Jul 2025 22:06:56 +0800 > > > > Cc: michael.albinus@gmx.de, kobarity@gmail.com, 79036@debbugs.gnu.org > > > > > > > > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii wrote: > > > > > > > > > > > file-exists-p: For a local file name in a remote python shell, we > > > > > > cannot simply distinguish whether it is a file on the remote system or > > > > > > a local file (i.e. sending code from local host), although the former > > > > > > is more likely. So we need file-exists-p for verification. > > > > > > > > > > Sorry, I don't understand the problem and its solution. What do you > > > > > mean by "local file name in a remote python shell"? > > > > > > > > For example, below is the pdb output in a remote python shell, and the > > > > file-name "/tmp/test.py" is local. Because of the "from ... import > > > > ...", we can know the file is on the remote system. > > > > > > > > >>> from test import f; f() > > > > > /tmp/test.py(3)f() > > > > -> return 1 > > > > (Pdb) > > > > > > > > However, with the following pdb output in a remote python shell > > > > > > > > >>> f() > > > > > /tmp/test.py(3)f() > > > > -> return 1 > > > > (Pdb) > > > > > > > > The local filename "/tmp/test.py" may be on the remote system like the > > > > above case, or may be on the local host if we press C-c C-c to send > > > > its code to the remote process. > > > > > > > > Which file should python shell track? The simplest solution is to > > > > check which file exists. > > > > > > Doesn't the value of default-directory tells us whether it's a local > > > or a remote file? If not, why not? > > > > In the example: > > > > >>> f() > > > /tmp/test.py(3)f() > > -> return 1 > > (Pdb) > > > > The current buffer is the Python shell buffer, default-directory is > > remote only means > > python process is remote. "/tmp/test.py" may be on the local host because users > > may send code in local file "/tmp/test.py" to the remote process. > > This cannot work reliably, and I don't think we should support it. > Please ignore this case in the following discussions. I agree that this method does not work reliably. However, I think we can take another approach. First, let me explain the problem. The inferior Python process is invoked on the remote host if the Python file buffer is remote. There are two buffers, both remote. 1. Python file buffer. 2. Inferior Python buffer. By default, the inferior Python buffer is shared among Python files. So if we open another local Python file, it uses the above remote inferior Python buffer. When we send the contents of the local file using C-c C-c to the inferior Python buffer, the local file name such as "/tmp/test.py" is passed. This results in the above problem. I think the file name without any prefix such as "/tmp/test.py" should be used when and only when the inferior Python process can handle it. When sending the local "/tmp/test.py" to the remote Python process, passing the file name "/tmp/test.py" is useless because there is no guarantee that the same "/tmp/test.py" exists on the remote host. Instead, I think it would be better to pass the file name with the prefix indicating that the file is local. The inferior Python process (PDB) itself still cannot handle that file name, but the PDB tracking feature can take advantage of it. If TRAMP supports a method such as "/local:" to access local files, we can use it. As TRAMP does not seem to have such a thing, I use "/ssh::" instead. The real "/ssh::" requires an SSH server to be running on the local host, but I'm just using it as a pseudo prefix to distinguish local files from remote files. i.e. SSH server is not required on local host. The case of multiple remote hosts should also be considered. In summary, it seems to me that it would be a good idea to pass the file names as shown in the following table. | | Local Python | Python on remote1 | |-------------------+---------------------+---------------------| | Local tmp.py | tmp.py | /ssh::tmp.py | | tmp.py on remote1 | /ssh:remote1:tmp.py | tmp.py | | tmp.py on remote2 | /ssh:remote2:tmp.py | /ssh:remote2:tmp.py | Local Python cases are already covered with current python.el. Attached is a PoC-level patch to support Remote Python cases. What do you think of this approach?