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:
Traceback (most recent call last):
File "\Python32\Scripts\ipython3-qtconsole-script.pyw", line 9, in
load_entry_point('ipython==0.12', 'gui_scripts', 'ipython3-qtconsole')()
File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 2280, in load_entry_point
return ep.load()
File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 1990, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "C:\Python32\lib\site-packages\IPython\__init__.py", line 43, in
from .config.loader import Config
File "C:\Python32\lib\site-packages\IPython\config\loader.py", line 27, in
from IPython.utils.path import filefind, get_ipython_dir
File "C:\Python32\lib\site-packages\IPython\utils\path.py", line 24, in
from IPython.utils.process import system
File "C:\Python32\lib\site-packages\IPython\utils\process.py", line 25, in
from ._process_win32 import _find_cmd, system, getoutput, AvoidUNCPath, arg_split
File "C:\Python32\lib\site-packages\IPython\utils\_process_win32.py", line 30, in
from . import text
File "C:\Python32\lib\site-packages\IPython\utils\text.py", line 30, in
from IPython.utils.io import nlprint
File "C:\Python32\lib\site-packages\IPython\utils\io.py", line 90, in
stdin = IOStream(sys.stdin)
File "C:\Python32\lib\site-packages\IPython\utils\io.py", line 32, in __init__
raise ValueError("fallback required, but not specified")
ValueError: fallback required, but not specified
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:
# this will show what the std* file handles are on Python 2.x vs Python 3.x
# noted @ http://bugs.python.org/issue1415
import sys
fname = 'python%d_std_fds.txt' % (sys.version_info[0])
f = open(fname, 'w')
if sys.stdin is None:
f.write("stdin: None\n")
else:
f.write("stdin: %i\n" % sys.stdin.fileno())
if sys.stdout is None:
f.write("stdout: None\n")
else:
f.write("stdout: %i\n" % sys.stdout.fileno())
if sys.stderr is None:
f.write("stderr: None\n")
else:
f.write("stderr: %i\n" % sys.stderr.fileno())
f.close()
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:
Traceback (most recent call last): File "\Python32\Scripts\ipython3-qtconsole-script.pyw", line 9, in load_entry_point('ipython==0.12', 'gui_scripts', 'ipython3-qtconsole')() File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 337, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 2280, in load_entry_point return ep.load() File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\pkg_resources.py", line 1990, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "C:\Python32\lib\site-packages\IPython\__init__.py", line 43, in from .config.loader import Config File "C:\Python32\lib\site-packages\IPython\config\loader.py", line 27, in from IPython.utils.path import filefind, get_ipython_dir File "C:\Python32\lib\site-packages\IPython\utils\path.py", line 24, in from IPython.utils.process import system File "C:\Python32\lib\site-packages\IPython\utils\process.py", line 25, in from ._process_win32 import _find_cmd, system, getoutput, AvoidUNCPath, arg_split File "C:\Python32\lib\site-packages\IPython\utils\_process_win32.py", line 30, in from . import text File "C:\Python32\lib\site-packages\IPython\utils\text.py", line 30, in from IPython.utils.io import nlprint File "C:\Python32\lib\site-packages\IPython\utils\io.py", line 90, in stdin = IOStream(sys.stdin) File "C:\Python32\lib\site-packages\IPython\utils\io.py", line 32, in __init__ raise ValueError("fallback required, but not specified") ValueError: fallback required, but not specifiedI 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: