I am rewriting PEP 597 to introduce a new EncodingWarning, which subclass of DeprecationWarning and used to warn about future default encoding change. But I don't think we can change the default encoding of `io.TextIOWrapper` and built-in `open()` anytime soon. It is disruptive change. It may take 10 or more years.
To ease the pain caused by "default encoding is not UTF-8 (almost) only on Windows" (*), I came up with another idea. This idea is not mutually exclusive with PEP 597, but I want to include it in the PEP because both ideas use EncodingWarning.
(*) Imagine that a new Python user writes a text file with notepad.exe (default encoding is UTF-8 without BOM already) or VS Code, and try to read it in Jupyter Notebook. They will see UnicodeDecodeError. They might not know about what encoding yet.
## 1. Add `io.open_text()`, builtin `open_text()`, and `pathlib.Path.open_text()`.
All functions are same to `io.open()` or `Path.open()`, except:
* Default encoding is "utf-8". * "b" is not allowed in the mode option.
These functions have two benefits:
* `open_text(filename)` is shorter than `open(filename, encoding="utf-8")`. Its easy to type especially with autocompletion. * Type annotation for returned value is simple than `open`. It is always TextIOWrapper.
## 2. Change the default encoding of `pathlib.Path.read_text()`.
For convenience and consistency with `Path.open_text()`, change the default encoding of `Path.read_text()` to "utf-8" with regular deprecation period.
* Python 3.10: `Path.read_text()` emits EncodingWarning when the encoding option is omitted. * Python 3.13: `Path.read_text()` change the default encoding to "utf-8".
If PEP 597 is accepted, users can pass `encoding="locale"` instead of `encoding=locale.getpreferredencoding(False)` when they need to use locale encoding.
We might change more places where the default encoding is used. But it should be done slowly and carefully.
How do you think about this idea? Is this worth enough to add a new built-in function?