Nick Coghlan <ncogh...@gmail.com> added the comment:
Reviewing the diff at https://github.com/python/cpython/compare/v3.7.1...v3.7.2 the only item I've spotted that seems like it could even plausibly be related is the tweak at https://github.com/python/cpython/compare/v3.7.1...v3.7.2#diff-baf5eab51059d96fb8837152dab0d1a4 (Click the Files tab to get your browser to jump to the anchor in the second link) That's a change to the function that emits the "Fatal Python error: initfsencoding: unable to load the file system codec" message. That change means that embedding applications could potentially be hitting the codec name resolution at https://github.com/python/cpython/blob/3.7/Python/pylifecycle.c#L1643 with the filesystem encoding set as "ascii", rather than handling that case through the "get_locale_encoding()" branch, which does the initial codec name lookup with the filesystem encoding still set to NULL (and hence falling back to the locale encoding as the default). However, the only way that new branch could trigger is if check_force_ascii() (at https://github.com/python/cpython/blob/v3.7.2/Python/fileutils.c#L100 ) is returning 1 for some reason, which we only expect it to do on some misbehaving BSD OSes, not on Windows: https://github.com/python/cpython/pull/10233 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35596> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
