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 <[email protected]> wrote:
>
> On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett <[email protected]> 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 <[email protected]>
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/MSK5HN4IGUMBRF4PM7IZYMI7OJGD4KJC/
Code of Conduct: http://python.org/psf/codeofconduct/
