STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> "I think that using ASCII is a safer choice in case of errors. (...) Ouch, that was a poor choice."
> 
> Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can you review my last patch please?

I don't think we can change the fallback encoding in 3.2. But you
can start a discussion on python-dev, of course.

The number of Python 3.x users is still small, so perhaps it's still
possible to revert the choice and to use a safer default, which then
results in encoding errors that the user can see in form of tracebacks
rather than just by having actively checking the directory listing
for strange symbols.

Some comments on the patch:

+		fprintf(stderr,
+			"Unable to get the locale encoding: "
+			"fallback to utf-8\n");

This would have to read "... to ASCII"

+		Py_FileSystemDefaultEncoding = "ascii";

+	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.

Fatal errors are just not user friendly and will likely cause
bad vibes towards Python3.

E.g.

		fprintf(stderr,
			"Unknown locale encoding: "
			"fallback to ASCII\n");

You also need to change this line in pythonrun.c:

        /* reset file system default encoding */
        if (!Py_HasFileSystemDefaultEncoding) {
                free((char*)Py_FileSystemDefaultEncoding);
                Py_FileSystemDefaultEncoding = NULL;
        }

I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
is. If we define a default for the file system encoding,
then why do we bother whether there is one ?

In any case, initfsencoding() would always have to set that
flag to 1.