GNU bug report logs - #25025
python-shell-calculate-command is wrong

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25025 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: bug#25025: python-shell-calculate-command is wrong
Date: Thu, 01 Dec 2016 19:10:50 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Wed, 30 Nov 2016 17:10:34 -0500
> Cc: Clément Pit--Claudel <clement.pit <at> gmail.com>, 
> 	25025 <at> debbugs.gnu.org
> 
> > Confused: how does python-shell-completion-native-disabled-interpreters
> > get into this picture?  The function which uses it,
> > python-shell-completion-native-interpreter-disabled-p, looks at
> > python-shell-interpreter, which isn't affected by quoting or by how
> > the command is treated.  What am I missing?
> 
> This?
> 
> (defun run-python (&optional cmd dedicated show)
>   ...
>    (python-shell-make-comint
>     (or cmd (python-shell-calculate-command))
>   ...
> 
> (defun python-shell-make-comint (cmd proc-name &optional show internal)
>   ...
>           (let* ((cmdlist (split-string-and-unquote cmd))
>                  (interpreter (car cmdlist))
>                  (args (cdr cmdlist))
>                  (buffer (apply #'make-comint-in-buffer proc-name
> proc-buffer-name
>                                 interpreter nil args))
>                  ...
>                  ;; Users can override the interpreter and args
>                  ;; interactively when calling `run-python', let-binding
>                  ;; these allows having the new right values in all
>                  ;; setup code that is done in `inferior-python-mode',
>                  ;; which is important, especially for prompt detection.
>                  (python-shell--interpreter interpreter)
>                  (python-shell--interpreter-args
>                   (mapconcat #'identity args " ")))
>             (with-current-buffer buffer
>               (inferior-python-mode))
>   ...
> 
> (define-derived-mode inferior-python-mode comint-mode "Inferior Python"
>   ...
>   ;; Users can interactively override default values for
>   ;; `python-shell-interpreter' and `python-shell-interpreter-args'
>   ;; when calling `run-python'.  This ensures values let-bound in
>   ;; `python-shell-make-comint' are locally set if needed.
>   (set (make-local-variable 'python-shell-interpreter)
>        (or python-shell--interpreter python-shell-interpreter))
>   (set (make-local-variable 'python-shell-interpreter-args)
>        (or python-shell--interpreter-args python-shell-interpreter-args))
>   ...

Thanks.

So the problematic scenario is that the user sets
python-shell-interpreter to something we already checked, and then
manually feeds us with a command that invokes a different Python
interpreter, is that it?  Is that a frequent use case, which we
should care about?  Just to produce a warning?

Even if we do want to care about, we could try matching the beginning
of the command, perhaps after an optional quote character, and if we
don't recognize the interpreter, do nothing.  Would that be
sufficient?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.