<div dir="ltr">> BTW. “cp874” does exist according to the unicode consortium: <a href="https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT" target="_blank" rel="nofollow">https://www.<wbr>unicode.org/Public/MAPPINGS/<wbr>VENDORS/MICSFT/WINDOWS/CP874.<wbr>TXT</a>, and appears to be a codepage for a (the?) Thai language.  The user might therefore be running Windows with a Thai locale.<div><br></div><div><a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx">This page</a> also lists 874 along with windows-874 as .NET name belonging to Thai language and doesn't mention cp-874. I don't have knowledge of .NET but just wanted to add this as a reference.<br></div><div><br></div><div>One another disadvantage of patching the search function (or adding any alias for digit only encoding assuming cpXXXX) is that it prepends "cp" and it also assumes that aliases.py that takes precedence doesn't resolve correctly. Since some of the digit only encodings like '936' that corresponds to 'gbk' are added in aliases.py they don't get resolved as 'cp936' for now. But if new digit only and non-cp encodings are added in future then they have to be added to the file so that precedence works instead of always resolving to cpXXXX encoding. I think this is noted at https://bugs.python.org/issue33865#msg319617.</div><div><br></div><div>It would be nice if the original poster provided some more context or environment to reproduce it than the screenshot which has limited information. I am keeping aside the search_function.patch and look forward to OP to reply back in the issue.<br></div><div><br></div><div>Thanks</div><div><br></div><div>PS : This is my first mailing list post. Kindly ignore if I am using wrong quoting mechanism.<br></div><div><br></div>On Monday, June 18, 2018 at 12:01:01 AM UTC+5:30, Ronald Oussoren wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 17 Jun 2018, at 14:02, Stephen J. Turnbull <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="BaGdoZNKBAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">turnbull....@u.<wbr>tsukuba.ac.jp</a>> wrote:</div><br><div><div>Folks.  There are standards.  "1252" *is not* an alias for<br>"windows-1252" according to the IANA, while "866" *is* an alias for<br>"IBM866" according to the same authority.  Most 3-digit "IBMxxx" ARE<br>aliased to both "cpxxx" and just "xxx", but not all.  None of<br>"IBM874", "874", or "cp874" exists according to the IANA.<br></div></div></blockquote><div><br></div></div>Sure, but for at least one user Python 3.6 fails to start because initialising the sys.std* streams fails due to not finding a “874” encoding.   <div><br></div><div>The user sadly enough didn’t provide more information on his machine, other than that it is running some version of Windows. </div><div><br></div><div>BTW. “cp874” does exist according to the unicode consortium: <a href="https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.unicode.org%2FPublic%2FMAPPINGS%2FVENDORS%2FMICSFT%2FWINDOWS%2FCP874.TXT\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHs2hBuJqsXG5taeq5FM2KiQWjJGw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.unicode.org%2FPublic%2FMAPPINGS%2FVENDORS%2FMICSFT%2FWINDOWS%2FCP874.TXT\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHs2hBuJqsXG5taeq5FM2KiQWjJGw';return true;">https://www.<wbr>unicode.org/Public/MAPPINGS/<wbr>VENDORS/MICSFT/WINDOWS/CP874.<wbr>TXT</a>, and appears to be a codepage for a (the?) Thai language.  The user might therefore be running Windows with a Thai locale.</div><div><br></div><div>Ronald</div><div><br></div><div><br></div></div></blockquote></div>