STINNER Victor wrote:
> 
>> +	codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
>> +	if (!codec) {
>> +		Py_FatalError(
>> +		    "Py_Initialize: unable to load the file system codec");
>>
>> It's better to use the same approach as above for this situation
>> as well.
> 
> I choosed to display a fatal error here to give a more revelant error message 
> to the user. Without the check, _PyCodec_Lookup() will fail anyway, but later 
> in a random function :-/
> 
> The fatal error only occurs in critical situations: no more memory, import 
> machinery completly broken (eg. #8611), etc. In this case, fallback to ASCII 
> doesn't help, it will also raise somewhere later.
> 
> About nl_langinfo(CODESET): get_codeset() does already reject unknown 
> encoding. So this call is only done on known encoding names.

Ok, please add a comment to that part explaining why it can only
fail as result of some other serious error and not because
the Py_FileSystemDefaultEncoding was not found to be supported
by Python.

>> I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
>> is.
> 
> Its name doesn't help. It's just a flag to tell if free() should be called or 
> not... (see _Py_SetFileSystemEncoding()).

Interesting... I would associate a completely different meaning
with it.

Scratch my comment on that flag then.

>> In any case, initfsencoding() would always have to set that
>> flag to 1.
> 
> initfsencoding() is a static function and it's only called by 
> Py_InitializeEx(). Can Py_InitializeEx() be called multiple times?

Well, it shouldn't be called multiple times, but then you never
know how embedded Python interpreters are used.