On 23Aug2016 2150, Stephen J. Turnbull wrote:
Steve Dower writes:
> * Stephen sees "no reason not to change locale.getpreferredencoding()"
> (default encoding for open()) at the same time with the same switches,
> while I'm not quite as confident. Do users generally specify an encoding
> these days? I know I always put utf-8 there.
I was insufficiently specific. "No reason not to" depends on separate
switches for file system encoding and preferred encoding. That makes
things somewhat more complicated for implementation, and significantly
so for users.
Yes, it does, but it's about the only possible migration path.
I know Nick and Victor like the idea of a -X flag (or a direct -utf8
flag), but I prefer more specific environment variables:
- PYTHONWINDOWSLEGACYSTDIO (for the console changes)
- PYTHONWINDOWSLEGACYPATHENCODING (assuming getfilesystemencoding() is utf8)
- PYTHONWINDOWSLEGACYLOCALEENCODING (assuming getpreferredencoding() is
utf8)
I'm open to dropping "WINDOWS" from these if others don't think it's
necessary. Swap "LEGACY" for "UNICODE" if we just offer the option to
upgrade now rather than changing the default.
(I could also see the possibility of PYTHONWINDOWSSTRICT* options to use
the default encoding but raise if decoding bytes fails - mbcs:strict
rather than mbcs:replace. For utf-8 mode I'd want to use surrogatepass
throughout, so it will always raise on invalid encoding, but there will
be far fewer occurrences than for mbcs.)
I'll transform my earlier post into a PEP (or probably three PEPs - one
for each change), since it seems like the paper trail is going to be
more valuable than discussing it now. Without an actual build to test
it's pretty hard to evaluate the impact.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
