> Please see https://bugs.python.org/issue47000#msg415769 for what Victor
> suggested.

Of course, I read it.

> In particular, the locale module uses the "no underscore" convention.
> Not sure whether it's good to start using snake case now, but I'm also
> not against it.

Victor didn't mention about "no underscore" convention.
I just want to see preference from others. I will remove the underscore.

> I would like to reiterate my concern with the "locale" encoding, though.
>
> As mentioned earlier, I believe it adds too much magic. It would be better
> to leave this in the hands of the applications and not try to guess
> the correct encoding.

I don't recommend to use "locale" encoding for users.
I strongly recommend to consider using "utf-8" instead.
But "locale" encoding is needed when user don't want to change behavior of current application.
It had been accepted by PEP 597 already.

> It's better to expose easy to use APIs to access the various different
> settings and point users to those rather than try to do a best effort
> guess... explicit is better than implicit.

In some case, user need to decide "not change the encoding for now".
If we don't provide "locale", it's difficult to change the default encoding to UTF-8.

> After all, Mojibake potentially corrupts important data, without the
> alerting the user and that's not really what we should be after (e.g.
> UTF-8 is valid Latin-1 in most cases and this is a real problem we often
> run into in Germany with our Umlauts).

Changing the default encoding will temporary increase this risk.
But after changing the default encoding to UTF-8, this risk will be reduced overwhelmingly.
Most popular text editors, including VSCode, Atom, Sublime Text, Notepad.exe use UTF-8 by default.