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 ned.deily, serhiy.storchaka, taleinat, terry.reedy
Date 2020-06-29.05:02:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The main use for the iomenu settings is for the socket-transport file classes, in  The default encoding='utf-8' and errors='strict' are not used but are overriden with the iomenu values, or for stderr, 'backslashreplace'.

Since user code can print any unicode, I think the defaults should used as is to transparently pass on and possibly display anything the user sends.  Such a change should have no back-compatibility issues.

Thinking more about errors.  With utf-8 encoding of proper strings, there should never be any, but Python does allow construction of 'improper' strings with, say, single surrogates.  The transport mechanism should never raise, so maybe surrogateescape or backslashreplace should always be used. 

What do you two think?

Another use is for writing bytes to an OutputWindow, as with find-in-files.  But I can think of no case where IDLE sends bytes to an OutputWindow.  User files are all opened in an editor.

I believe these are all the uses of 'iomenu.encoding' outside of iomenu.  'from iomenu ...' is never used.

Within iomenu, the only use is part of reading an encoding cookie.
    # The only use of 'encoding' below is in _decode as initial value
    # of deprecated block asking user for encoding.
I am not sure if this use can be reached now.  Even if so, I believe this code duplicates code elsewhere in the stdlib that might be used.

So maybe the encoding calculation is not really needed.
Date User Action Args
2020-06-29 05:02:28terry.reedysetrecipients: + terry.reedy, taleinat, ned.deily, serhiy.storchaka
2020-06-29 05:02:27terry.reedysetmessageid: <>
2020-06-29 05:02:27terry.reedylinkissue41152 messages
2020-06-29 05:02:27terry.reedycreate