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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4