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

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Wed, Nov 30, 2016 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: npostavs@users.sourceforge.net
>> Cc: Eli Zaretskii <eliz@gnu.org>,  25025@debbugs.gnu.org
>> Date: Tue, 29 Nov 2016 20:56:16 -0500
>>
>> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>>
>> > On 2016-11-29 19:36, npostavs@users.sourceforge.net wrote:
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >>>> From: npostavs@users.sourceforge.net
>> >>>> Cc: 25025@debbugs.gnu.org,  clement.pit@gmail.com
>> >>>> Date: Sun, 27 Nov 2016 11:06:03 -0500
>> >>>>
>> >>>>> Why does it need to be split?  A shell command can (even should) be
>> >>>>> handed to the shell as a single string.
>> >>>>
>> >>>> Currently it's not a shell command, because a shell isn't being used.
>> >>>> My other suggestion was to use a shell:
>> >>>>
>> >>>>>> It might be more intuitive to actually use a shell and then the user
>> >>>>>> would enter a shell command (though inserting a shell into things
>> >>>>>> might bring more complications).
>> >>>
>> >>> If it doesn't use a shell, then it has no business quoting commands or
>> >>> their parts using shell-related APIs.
>> >>>
>> >>> So yes, I think using a shell would be TRT here.  Can someone please
>> >>> work on a patch in that direction?  This problem exists for a long
>> >>> time, so I hope we could solve it soon.
>> >>
>> >> Hmm, the difficulty in using a shell is that the current code wants to
>> >> parse the command into interpreter and arguments in order to match
>> >> against `python-shell-completion-native-disabled-interpreters'.
>> >
>> > That doesn't prevent us from using a shell.  We run the command
>> > unmodified through a shell, and we split it and analyze it separately
>> > to decide whether to enable completion.  But we don't split and
>> > reassemble it before running it.
>>
>> Yes, but then we need to parse a shell quoted command, which is quite a
>> bit more difficult.  That gets back to your suggestion about getting an
>> elisp equivalent to shlex I suppose.
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25025#28
>
> 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))
  ...