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 ncoghlan
Recipients brett.cannon, eric.snow, hyu, miss-islington, ncoghlan, ned.deily, paul.moore, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-12-28.15:02:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Reviewing the diff at the only item I've spotted that seems like it could even plausibly be related is the tweak at

(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 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 ) is returning 1 for some reason, which we only expect it to do on some misbehaving BSD OSes, not on Windows:
Date User Action Args
2018-12-28 15:02:42ncoghlansetrecipients: + ncoghlan, brett.cannon, paul.moore, vstinner, tim.golden, ned.deily, eric.snow, zach.ware, serhiy.storchaka, steve.dower, miss-islington, hyu
2018-12-28 15:02:41ncoghlansetmessageid: <>
2018-12-28 15:02:41ncoghlanlinkissue35596 messages
2018-12-28 15:02:41ncoghlancreate