On Sat, Jan 23, 2021 at 10:51 PM Chris Angelico email@example.com wrote:
On Sun, Jan 24, 2021 at 2:46 PM Matt Wozniski firstname.lastname@example.org wrote:
- At the same time as the deprecation is announced, introduce a new
__future__ import named "utf8_open" or something like that, to opt into the future behavior of `open` defaulting to utf-8-sig or utf-8 when opening a file in text mode and no explicit encoding is specified.
I think a __future__ import solves the problem better than introducing a
new function would.
Note that, since this doesn't involve any language or syntax changes, a regular module import would work here - something like "from utf8mode import open", which would then shadow the builtin. Otherwise no change to your proposal - everything else works exactly the same way.
True - that's an even better idea. That even allows it to be wrapped in a try/except ImportError, allowing someone to write code that's backwards compatible to versions before the new function is introduced. Though it does mean that the new function will need to stick around, even though it will eventually be identical to the builtin open() function.
That would also allow the option of introducing a locale_open as well, which would behave as though encoding=locale.getpreferredencoding(False) is the default encoding for files opened in text mode. I can imagine putting both functions in io, and allowing the user to silence the deprecation warning by either opting into the new behavior:
from io import utf8_open as open
or explicitly declaring their desire for the legacy behavior:
from io import locale_open as open