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 terry.reedy
Recipients anthonypjshaw, asvetlov, cheryl.sabella, ggenellina, ned.deily, terry.reedy
Date 2019-05-06.20:50:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Good question.  There are two issues when starting IDLE with pythonw.exe, so that sys.__stderr__ and sys.stderr are initially None.

1. None.write is an attribute error that crashes Python.  Therefore, don't do that. Instead use print.  By default, and when 'file=None' is given directly or by reference, print writes to sys.stdout if it exists or gives up otherwise.

I checked for possible (None).write code and did not find any except where commented out.  These should be deleted or converted to prints.  Possible None files are passed to traceback.print_exception and traceback.print_stack and these both use print, not write.

All but two of the stderr crash issues Roger listed in msg149414 are closed, and the last two either should be or should have a different problem.

Still relevant is

2. Unprinted messages cannot be read by the user.  So display them in a text widget.

Open question 1: backup to print?, default display method?, or both (when possible)?  Ned implies that both would be good on Mac, and maybe
same would be true everywhere.

Open question 2: what patch?  I need to consider Roger's patch in relation to idlelib changes since, including new PseudoFiles, changes to text viewer, and new query module.

The above is about sys in the IDLE GUI process.  The user code process is started with sys.executable, and sys.stdout and sys.stderr are replaced with Pseudofiles that direct output to the idle process shell.  The value of sys.__stdout__ and __stderr__ depend on sys.executable.  If None, prints will go to sys.stdout and hence Shell, and writes raise AttributeError, which also appears in the Shell.  If normal, prints and writes go to the console.  I should check if enough of this is in the docs.

It might be a good idea to wrap both processes in a top-level try-except to attempt to display any unexpected internal error.

I will clean the nosy list as this issue does not involve Steve Dower and many others are long inactive.
Date User Action Args
2019-05-06 20:50:56terry.reedysetrecipients: + terry.reedy, ggenellina, ned.deily, asvetlov, cheryl.sabella, anthonypjshaw
2019-05-06 20:50:56terry.reedysetmessageid: <>
2019-05-06 20:50:55terry.reedylinkissue13582 messages
2019-05-06 20:50:55terry.reedycreate