In the documentation (not sure whether it should be the documentation for "open" or for encoding), include at least a link to instructions on how to (try to) verify that your codebase is using the encoding parameter properly. Those instructions would say something like "Add the following lines to end of Lib\site.py: _origopen=open def open(...): if ... warnings.warn(...) _origopen(...) " -jJ On Fri, Feb 12, 2021 at 6:28 PM Inada Naoki <songofacandy@gmail.com> wrote:
On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett <jimjjewett@gmail.com> wrote:
Offering encoding="locale" (or open.locale or ... ) instead of a long function call using False (locale.getpreferredencoding(False)) seems like a win for Explicit is Better Than Implicit. It would then be possible to say "yeah, locale really is what I meant".
Err... unless the charset determination is so tricky that it ends up just adding another not-quite-right near-but-not-exact-synonym.
Adding a new Warning subclass, and maybe a new warning type, and maybe a new environment variable, and maybe a new launch flag ... these all seem to risk just making things more complicated without sufficient gain.
Would a recipe for site-packages be sufficient, or does this need to run too early in the bootstrapping process?
-jJ
What does "a recipe for site-packages" mean?
-- Inada Naoki <songofacandy@gmail.com>