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

Previous Next

Full log

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 25.0.50; MS-Windows needs a different default for
 python-shell-interpreter-args
Date: Fri, 14 Nov 2014 16:29:23 +0200

> From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Fri, 14 Nov 2014 10:05:28 -0300
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
> >> Cc: bug-gnu-emacs <at> 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?

Previous Next

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