bug#25025: python-shell-calculate-command is wrong

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 30 Nov 2016 17:10:34 -0500
> Cc: Clément Pit--Claudel <clement.pit@gmail.com>, 
> 	25025@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?