bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

With the default value, 'run-python' hangs in accept-process-output.
This fixes that for me:

--- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
+++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
@@ -1739,7 +1739,8 @@
   :group 'python
   :safe 'stringp)
 
-(defcustom python-shell-interpreter-args "-i"
+(defcustom python-shell-interpreter-args
+  (if (eq system-type 'windows-nt) "-i -u" "-i")
   "Default arguments for the Python interpreter."
   :type 'string
   :group 'python)


In GNU Emacs 25.0.50.10 (i686-pc-mingw32)
 of 2014-10-01 on HOME-C4E4A596F7
Repository revision: 117996 dmantipov@yandex.ru-20141001132108-zdsxru2390mqyjlu
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0
 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 78619 5657)
 (symbols 32 17980 0)
 (miscs 32 36 97)
 (strings 16 12837 3606)
 (string-bytes 1 313654)
 (vectors 8 9980)
 (vector-slots 4 389907 2806)
 (floats 8 64 199)
 (intervals 28 240 95)
 (buffers 516 11))

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Glenn Morris]

Eli Zaretskii wrote:

> With the default value, 'run-python' hangs in accept-process-output.
> This fixes that for me:
>
> --- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
> +++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
> @@ -1739,7 +1739,8 @@
>    :group 'python
>    :safe 'stringp)
>  
> -(defcustom python-shell-interpreter-args "-i"
> +(defcustom python-shell-interpreter-args
> +  (if (eq system-type 'windows-nt) "-i -u" "-i")

Should this be in emacs-24?
(So no-one has ever used it on MS Windows?)

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 18596@debbugs.gnu.org
> Date: Wed, 01 Oct 2014 12:48:06 -0400
> 
> Eli Zaretskii wrote:
> 
> > With the default value, 'run-python' hangs in accept-process-output.
> > This fixes that for me:
> >
> > --- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
> > +++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
> > @@ -1739,7 +1739,8 @@
> >    :group 'python
> >    :safe 'stringp)
> >  
> > -(defcustom python-shell-interpreter-args "-i"
> > +(defcustom python-shell-interpreter-args
> > +  (if (eq system-type 'windows-nt) "-i -u" "-i")
> 
> Should this be in emacs-24?

I wasn't sure it was important enough.  I can back-port (given that
the maintainer agrees to the fix).

> (So no-one has ever used it on MS Windows?)

This is just the default value of the defcustom, one could customize
it and solve the problem.  I guess whoever used this did that.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:

> With the default value, 'run-python' hangs in accept-process-output.
> This fixes that for me:
>
> --- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
> +++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
> @@ -1739,7 +1739,8 @@
>    :group 'python
>    :safe 'stringp)
>  
> -(defcustom python-shell-interpreter-args "-i"
> +(defcustom python-shell-interpreter-args
> +  (if (eq system-type 'windows-nt) "-i -u" "-i")
>    "Default arguments for the Python interpreter."
>    :type 'string
>    :group 'python)
>

That makes things a little bit more annoying for the user as it breaks
changing from python to ipython easily since latter doesn't support the
"-u" switch.

I'll check this over the weekend to see if there's a better way to solve
this hang on Windows.


Thanks,
Fabián

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Thu, 02 Oct 2014 21:51:40 -0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > With the default value, 'run-python' hangs in accept-process-output.
> > This fixes that for me:
> >
> > --- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
> > +++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
> > @@ -1739,7 +1739,8 @@
> >    :group 'python
> >    :safe 'stringp)
> >  
> > -(defcustom python-shell-interpreter-args "-i"
> > +(defcustom python-shell-interpreter-args
> > +  (if (eq system-type 'windows-nt) "-i -u" "-i")
> >    "Default arguments for the Python interpreter."
> >    :type 'string
> >    :group 'python)
> >
> 
> That makes things a little bit more annoying for the user as it breaks
> changing from python to ipython easily since latter doesn't support the
> "-u" switch.

You could remove the -u when invoking ipython.

> I'll check this over the weekend to see if there's a better way to solve
> this hang on Windows.

Thanks.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

Ping!

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Thu, 02 Oct 2014 21:51:40 -0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > With the default value, 'run-python' hangs in accept-process-output.
> > This fixes that for me:
> >
> > --- lisp/progmodes/python.el~0	2014-10-01 06:33:59 +0300
> > +++ lisp/progmodes/python.el	2014-10-01 18:10:48 +0300
> > @@ -1739,7 +1739,8 @@
> >    :group 'python
> >    :safe 'stringp)
> >  
> > -(defcustom python-shell-interpreter-args "-i"
> > +(defcustom python-shell-interpreter-args
> > +  (if (eq system-type 'windows-nt) "-i -u" "-i")
> >    "Default arguments for the Python interpreter."
> >    :type 'string
> >    :group 'python)
> >
> 
> That makes things a little bit more annoying for the user as it breaks
> changing from python to ipython easily since latter doesn't support the
> "-u" switch.
> 
> I'll check this over the weekend to see if there's a better way to solve
> this hang on Windows.
> 
> 
> Thanks,
> Fabián
> 

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!
>

Hi Eli,

Sorry for the delay but I wanted to have a Windows machine at hand to
test this.

FYI I tested this with Windows 7, Python 3.3, 3.4 and 2.7.8 and wasn't
able to replicate it.  The interpreter started without hanging.

It also worked on Windows XP With Python 2.7, so my best guess is that
this is a very especific problem that only happens with some particular
combination of Windows and Python version (I recall something similar in
an old bug).

Could you tell me those versions?

And if you are still being able to replicate this issue, does this patch
help?:

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 122f4ec..018ebd0 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -94,13 +94,16 @@
 ;;       python-shell-interpreter-args
 ;;       "-i C:\\Python27\\Scripts\\ipython-script.py")
 
-;; If you are experiencing missing or delayed output in your shells,
-;; that's likely caused by your Operating System's pipe buffering
-;; (e.g. this is known to happen running CPython 3.3.4 in Windows 7.
-;; See URL `http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17304').  To
-;; fix this, using CPython's "-u" commandline argument or setting the
+;; Hangs, missing and/or delayed output in shells were known to happen
+;; on Windows, if you are experiencing a similar behavior, that's
+;; likely caused by your Operating System's pipe buffering (e.g. this
+;; used to happen running CPython 3.3.4 in Windows 7.  See URL
+;; `http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17304').  To fix
+;; this, using CPython's "-u" commandline argument or setting the
 ;; "PYTHONUNBUFFERED" environment variable should help: See URL
-;; `https://docs.python.org/3/using/cmdline.html#cmdoption-u'.
+;; `https://docs.python.org/3/using/cmdline.html#cmdoption-u'.  For
+;; Windows "PYTHONUNBUFFERED" is set to "1" automatically by
+;; `python-shell-calculate-process-environment`.
 
 ;; The interaction relies upon having prompts for input (e.g. ">>> "
 ;; and "... " in standard Python shell) and output (e.g. "Out[1]: " in
@@ -2095,7 +2098,11 @@ uniqueness for different types of configurations."
   "Calculate process environment given `python-shell-virtualenv-root'."
   (let ((process-environment (append
                               python-shell-process-environment
-                              process-environment nil))
+                              process-environment
+                              ;; Avoid hangs on Windows out of the
+                              ;; box.  See Bug#18595 and Bug#18596.
+                              (when (eq system-type 'windows-nt)
+                                '("PYTHONUNBUFFERED=1"))))
         (virtualenv (if python-shell-virtualenv-root
                         (directory-file-name python-shell-virtualenv-root)
                       nil)))



Thanks,
Fabián

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Fri, 14 Nov 2014 04:25:01 -0300
> 
> FYI I tested this with Windows 7, Python 3.3, 3.4 and 2.7.8 and wasn't
> able to replicate it.  The interpreter started without hanging.

How did you try this?  The recipe that (still) hangs for me is the one
used by the test suite:

  (run-python (executable-find "python") nil)

> It also worked on Windows XP With Python 2.7, so my best guess is that
> this is a very especific problem that only happens with some particular
> combination of Windows and Python version (I recall something similar in
> an old bug).
> 
> Could you tell me those versions?

Both Windows 7 and XP, Python 2.6.6.

> And if you are still being able to replicate this issue, does this patch
> help?:

I prefer to wait for you to try the above recipe and tell me if you
can reproduce the problem.  If you can't, I will try the patch.

Thanks.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
>> Cc: bug-gnu-emacs@gnu.org
>> Date: Fri, 14 Nov 2014 04:25:01 -0300
>> 
>> FYI I tested this with Windows 7, Python 3.3, 3.4 and 2.7.8 and wasn't
>> able to replicate it.  The interpreter started without hanging.
>
> How did you try this?  The recipe that (still) hangs for me is the one
> used by the test suite:
>
>   (run-python (executable-find "python") nil)
>

I tried this one by starting the interpreter as a user would and since
the "-i" is in the default interpreter arguments the shell doesn't hang.

>> It also worked on Windows XP With Python 2.7, so my best guess is that
>> this is a very especific problem that only happens with some particular
>> combination of Windows and Python version (I recall something similar in
>> an old bug).
>> 
>> Could you tell me those versions?
>
> Both Windows 7 and XP, Python 2.6.6.
>
>> And if you are still being able to replicate this issue, does this patch
>> help?:
>
> I prefer to wait for you to try the above recipe and tell me if you
> can reproduce the problem.  If you can't, I will try the patch.
>

I can only recreate the hang if I remove the "-i" switch in the default
command, so I think the real issue here is to fix how tests define the
command to run rather than changing the defaults on python.el.  With
this said, I think this bug should be closed and we should move to
#18595.




Regards,
Fabián

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Fri, 14 Nov 2014 10:05:28 -0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> >> Cc: bug-gnu-emacs@gnu.org
> >> Date: Fri, 14 Nov 2014 04:25:01 -0300
> >> 
> >> FYI I tested this with Windows 7, Python 3.3, 3.4 and 2.7.8 and wasn't
> >> able to replicate it.  The interpreter started without hanging.
> >
> > How did you try this?  The recipe that (still) hangs for me is the one
> > used by the test suite:
> >
> >   (run-python (executable-find "python") nil)
> >
> 
> I tried this one by starting the interpreter as a user would and since
> the "-i" is in the default interpreter arguments the shell doesn't hang.

I'm not sure what that means.  If it means you used "M-x run-python",
then that's not the use case I'm talking about.  I'm talking about the
above recipe.

> >> It also worked on Windows XP With Python 2.7, so my best guess is that
> >> this is a very especific problem that only happens with some particular
> >> combination of Windows and Python version (I recall something similar in
> >> an old bug).
> >> 
> >> Could you tell me those versions?
> >
> > Both Windows 7 and XP, Python 2.6.6.
> >
> >> And if you are still being able to replicate this issue, does this patch
> >> help?:
> >
> > I prefer to wait for you to try the above recipe and tell me if you
> > can reproduce the problem.  If you can't, I will try the patch.
> >
> 
> I can only recreate the hang if I remove the "-i" switch in the default
> command, so I think the real issue here is to fix how tests define the
> command to run rather than changing the defaults on python.el.  With
> this said, I think this bug should be closed and we should move to
> #18595.

Are you saying that it is OK for the above form to hang?

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> I can only recreate the hang if I remove the "-i" switch in the default
>> command, so I think the real issue here is to fix how tests define the
>> command to run rather than changing the defaults on python.el.  With
>> this said, I think this bug should be closed and we should move to
>> #18595.
>
> Are you saying that it is OK for the above form to hang?
>

Yes, on Windows the "-i" switch is required to avoid the hang and M-x
run-python does the right thing adding it by default.  We just need to
fix the tests so they don't forget about "-i".

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Fri, 14 Nov 2014 13:01:45 -0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> I can only recreate the hang if I remove the "-i" switch in the default
> >> command, so I think the real issue here is to fix how tests define the
> >> command to run rather than changing the defaults on python.el.  With
> >> this said, I think this bug should be closed and we should move to
> >> #18595.
> >
> > Are you saying that it is OK for the above form to hang?
> >
> 
> Yes, on Windows the "-i" switch is required to avoid the hang and M-x
> run-python does the right thing adding it by default.

I know that "M-x run-python" does that, but I think run-python itself
should do that, too.  It's a bug for it to hang like that.

> We just need to fix the tests so they don't forget about "-i".

That's a related, but separate problem.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
>> Cc: bug-gnu-emacs@gnu.org
>> Date: Fri, 14 Nov 2014 13:01:45 -0300
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> I can only recreate the hang if I remove the "-i" switch in the default
>> >> command, so I think the real issue here is to fix how tests define the
>> >> command to run rather than changing the defaults on python.el.  With
>> >> this said, I think this bug should be closed and we should move to
>> >> #18595.
>> >
>> > Are you saying that it is OK for the above form to hang?
>> >
>>
>> Yes, on Windows the "-i" switch is required to avoid the hang and M-x
>> run-python does the right thing adding it by default.
>
> I know that "M-x run-python" does that, but I think run-python itself
> should do that, too.  It's a bug for it to hang like that.
>

I don't agree, run-python will run whatever you tell it to run and while
I agree that malformed commands hanging it are not fun, that's the very
same reason why sane defaults are provided and why the commentary
section state possible problems clearly.

>> We just need to fix the tests so they don't forget about "-i".
>
> That's a related, but separate problem.
>

I'll focus on that alone, I'm still not convinced on the course of
action for this one.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs@gnu.org
> Date: Fri, 14 Nov 2014 17:55:40 -0300
> 
> >> > Are you saying that it is OK for the above form to hang?
> >> >
> >>
> >> Yes, on Windows the "-i" switch is required to avoid the hang and M-x
> >> run-python does the right thing adding it by default.
> >
> > I know that "M-x run-python" does that, but I think run-python itself
> > should do that, too.  It's a bug for it to hang like that.
> >
> 
> I don't agree, run-python will run whatever you tell it to run

I told it to run, not to hang!  And it doesn't hang on Unix, so it
shouldn't on Windows.

> and while I agree that malformed commands hanging it are not fun,
> that's the very same reason why sane defaults are provided and why
> the commentary section state possible problems clearly.

I'm surprised you consider documenting bugs to be a solution for those
bugs.  Bugs should be fixed, not documented.  If Emacs knows that in
certain situation it should invoke Python with -i, it should do that
automatically.  Or it should do something else to fix the hang, but
leaving the hanging behavior is IMO simply wrong, and even unbecoming.

> >> We just need to fix the tests so they don't forget about "-i".
> >
> > That's a related, but separate problem.
> >
> 
> I'll focus on that alone, I'm still not convinced on the course of
> action for this one.

I'm okay with any course of action, provided that the result will be
that the form I provided as recipe will not hang.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Stefan Monnier]

> I'm surprised you consider documenting bugs to be a solution for those
> bugs.  Bugs should be fixed, not documented.  If Emacs knows that in
> certain situation it should invoke Python with -i, it should do that
> automatically.  Or it should do something else to fix the hang, but
> leaving the hanging behavior is IMO simply wrong, and even unbecoming.

Adding "-i" to a command received as argument would definitely be
problematic, but if the command specified is "nil", I agree that we
should provide the needed args for the command to run correctly,
(i.e. include "-i").


        Stefan

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: fgallina@gnu.org (Fabián Ezequiel Gallina),
>   18596@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 19:29:43 -0500
> 
> > I'm surprised you consider documenting bugs to be a solution for those
> > bugs.  Bugs should be fixed, not documented.  If Emacs knows that in
> > certain situation it should invoke Python with -i, it should do that
> > automatically.  Or it should do something else to fix the hang, but
> > leaving the hanging behavior is IMO simply wrong, and even unbecoming.
> 
> Adding "-i" to a command received as argument would definitely be
> problematic

I agree.  When a command is given, run-python should obey it.  In this
case, it's the responsibility of whoever provides the command to make
it DTRT.

> but if the command specified is "nil", I agree that we should
> provide the needed args for the command to run correctly,
> (i.e. include "-i").

Obviously, I agree with that, too ;-)

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Fixed at 651ebee in the master branch.

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Date: Sun, 16 Nov 2014 11:21:54 -0300
> 
> 
> Fixed at 651ebee in the master branch.

Thanks.  But

  M-: (run-python (executable-find "python") nil) RET

still hangs for me on MS-Windows.  What am I missing?

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Fabián Ezequiel Gallina]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
>> Date: Sun, 16 Nov 2014 11:21:54 -0300
>> 
>> 
>> Fixed at 651ebee in the master branch.
>
> Thanks.  But
>
>   M-: (run-python (executable-find "python") nil) RET
>
> still hangs for me on MS-Windows.  What am I missing?
>

I believe we agreed on the fix being that the defaults should not hang.

The fact that your example hangs on Window is bad but it's not worth the
trouble of mangling the provided command and trying to add the "-i"
switch to it as it would break other cases.

From the Python help:

-i     : inspect interactively after running script; forces a prompt even
         if stdin does not appear to be a terminal; also PYTHONINSPECT=x
 
So I tried a solution that was ought to leave everyone happy, which was
setting PYTHONINSPECT env variable before run-python, but that didn't
help on Windows either.  If you have other ideas I'm eager to try them
out.


Thanks,
Fabián

bug#18596: 25.0.50; MS-Windows needs a different default for python-shell-interpreter-args

[Eli Zaretskii]

> From: fgallina@gnu.org (Fabián Ezequiel Gallina)
> Cc: 18596@debbugs.gnu.org
> Date: Sun, 16 Nov 2014 18:16:47 -0300
> 
> > Thanks.  But
> >
> >   M-: (run-python (executable-find "python") nil) RET
> >
> > still hangs for me on MS-Windows.  What am I missing?
> >
> 
> I believe we agreed on the fix being that the defaults should not hang.

Indeed.  Trouble is, it still does.

> The fact that your example hangs on Window is bad but it's not worth the
> trouble of mangling the provided command and trying to add the "-i"
> switch to it as it would break other cases.

We can add -i as long as the caller didn't provide a command.  I see
nothing wrong with this.  If you do, please explain why is it wrong.
Which other use cases will it break?

> >From the Python help:
> 
> -i     : inspect interactively after running script; forces a prompt even
>          if stdin does not appear to be a terminal; also PYTHONINSPECT=x
>  
> So I tried a solution that was ought to leave everyone happy, which was
> setting PYTHONINSPECT env variable before run-python, but that didn't
> help on Windows either.  If you have other ideas I'm eager to try them
> out.

I had another idea to begin with: add -i.  I also tested it and found
it to work in the use case I presented.

Thanks.