New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows GUI only (pythonw) bug for IPython on Python 3.x #1226
Comments
By hacking up IPython/utils/io.py variables to std{in,out,err} to make them None if corresponding sys.std{in,out,err} are None, and excepting cases elsewhere that blindly use sys.stding.encoding, and maybe one or two other minor hacks, I get the window up when starting ipython3-qtconsole.exe or pythonw ipython3-qtconsole-script.pyw. However, though I do see the Python version msg and IPython splash message, I never get the prompt. Tried various other things with the ipython3-qtconsole-script.pyw:
|
The banner but no prompt means that the frontend is starting, but it's failing to start or connect to the kernel. |
I was able to get better debugging information by installing Mark Hammond's pywin32 modules, and using logging.handlers.NTEventLogHandler to actually get some log data surrounding the failure (I didn't think the logging.handlers.FileHandler would work since both the GUI process and the Kernel process would be using the same name without some plumbing to provide different ones): --- a/IPython/config/application.py +++ b/IPython/config/application.py @@ -19,7 +19,7 @@ Authors: # Imports #----------------------------------------------------------------------------- -import logging +import logging.handlers import os import re import sys @@ -188,7 +188,7 @@ class Application(SingletonConfigurable): if sys.executable.endswith('pythonw.exe'): # this should really go to a file, but file-logging is only # hooked up in parallel applications - self._log_handler = logging.StreamHandler(open(os.devnull, 'w')) + self._log_handler = logging.handlers.NTEventLogHandler('ipython') else: self._log_handler = logging.StreamHandler() self._log_formatter = logging.Formatter("[%(name)s] %(message)s") And what I found was actually a generic Python 3 issue, that is only exposed because the no_stdout and no_stderr are both set to true for the kernel when run pythonw.exe. The problem is the use of Since open() works in both Python 2 and 3, my suggestion (or I can supply a patch, fork and make a pull request) is to replace all file() instances with open(). That still leaves some changes specific to having std{in,out,err} == None for pythonw.exe, but so far, things seem to work fine. |
I've got two commits in a fork at https://github.com/gbrandonp/ipython/tree/pythonw-py3k that have things working for me:
|
Great, thanks - please make a pull request from that branch so others review it. |
Pull request 1245 created |
This should now be fixed by PR #1245 - if anyone still encounters it, let us know. |
pythonw py3k fixes for issue ipython#1226
Trying to launch the ipython-qtconsole.exe or ipython-qtconsole-script.pyw via pythonw on Python 3.2 immediately exits, and the Qt console never starts. Running with ipython-qtconsole-script.pyw with plain python.exe works fine (and consumes the console). Fortunately, redirection stdout and stderr allows to get the traceback (well, stderr is where it went), which yields the following:
I was confused why nobody had seen this before, but come to find out it's a Python 3 vs 2 issue. sys.std* are now None (and will continue to be) for pythonw processes in Python 3.x, while they were file objects with fileno == -2 on Python 2.x. Regular old prints will work when stdout/stderr are None, but they just get discarded immediately, but of course any attribute lookups are going to fail.
Interestingly, running with:
\Python32\pythonw.exe \Python32\Scripts\ipython3-qtconsole-script.pyw > stdout.log 2> stderr.log < empty_file
yielded the qtconsole window, but the prompt never appeared, I assume due redirecting an empty file into stdin (I've no idea what /dev/null is on Windows). I guess in the course of normal script runs, that stdin is a file object that is already closed, or in some other state, so that allows this to work, but doesn't cause it to read input from stdin.
This simple script run with pythonw (on v2 and v3) highlights the difference:
The text was updated successfully, but these errors were encountered: