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

[Eli Zaretskii]

> 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?