On Tue, Feb 9, 2021 at 7:23 PM Victor Stinner
I recall that something like 1 year ago, I basically tried to implement something like your PEP, to see if the stdlib calls open() without specifying an encoding. There were so many warnings, that the output was barely readable.
The warning would only be useful if there is a way to modify the code to make the warning quiet (fix the issue) without losing support with Python 3.9 and older.
I understand that open(filename) must be replaced with open(filename, encoding=("locale" if sys.version_info >= (3, 10) else None)) to make it backward and forward compatibility without emitting an EncodingWarning.
I think most of them must be replaced with encoding="ascii" or encoding="utf-8". And encoding=locale.getpreferredencoding(False) is backward/forward compatible way. There is very little difference between encoding=None and encoding=locale.getpreferredencoding(False). But it is not a problem for most use cases. Only applications using PYTHONLEGACYWINDOWSSTDIO and open() for console I/O are affected by difference between them.
One issue is that some people may blindly copy/paste this code pattern without thinking if "locale" is the proper encoding.
Isn't it same if the code pattern become `encoding=getattr(io,
"LOCALE_ENCODING", None)`,
or `encoding=locale.getpreferredencoding(False)`?
I think only we can do is documenting the option like this:
"""
EncodingWarning is warning to find missing encoding="utf-8" option. It
is common pitfall that many Windows user
Don't try to fix them if you need to use locale specific encoding.
"""
--
Inada Naoki