This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients ezio.melotti, loewis, ned.deily, python-dev, roger.serwy, terry.reedy, vbr, vstinner
Date 2012-03-06.18:53:24
SpamBayes Score 1.3614121e-10
Marked as misclassified No
Message-id <1331060005.44.0.23218454398.issue14200@psf.upfronthosting.co.za>
In-reply-to
Content
That pythonw suddenly closes is a separate issue: if pythonw attempts to write to stderr, it crashes. To get your example to "run" in pythonw.exe,
try

pythonw.exe Lib\idlelib\idle.py 2> out.txt

I think the behavior of pythonw terminating when it can't write to stderr is actually correct: an exception is raised on attempting to write to stderr, which then can be printed (because there is no stderr).

So the real fault here is the traceback that python.exe reports.

To fix this, I think rpc.py should learn to marshal exceptions back to the subprocess. Then the initial sys.stdout.write should raise a UnicodeError (which it currently doesn't, either). This would get into the displayhook, which would then run use sys_displayhook_unencodable to backslashescape the unsupported character.

I'll attach a patch that at least makes the exception UnicodeEncodeError.
History
Date User Action Args
2012-03-06 18:53:25loewissetrecipients: + loewis, terry.reedy, vstinner, vbr, ned.deily, ezio.melotti, roger.serwy, python-dev
2012-03-06 18:53:25loewissetmessageid: <1331060005.44.0.23218454398.issue14200@psf.upfronthosting.co.za>
2012-03-06 18:53:24loewislinkissue14200 messages
2012-03-06 18:53:24loewiscreate