On 30 August 2016 at 08:38, Victor Stinner <victor.stinner at gmail.com> wrote: > Hi, > > tl; dr: just drop byte support and help developers to use Unicode in > their application! My view (and Steve's) is that this approach is likely to result in Linux-centric projects just dropping even nominal native Windows support, rather than more Python software that handles Unicode on Windows (/the CLR/the JVM) correctly. What Steve is proposing here is essentially a way of providing more *nix like CPython behaviour on Windows, just as the Windows Subsystem for Linux is Microsoft's latest iteration on providing such an environment at the kernel layer. This is why interoperability with other Windows programs isn't a major concern for this proposal - projects with Windows developers actually working on them that are designed to operate with other applications running on the same device (especially via files) should absolutely be using strings rather than bytes for interacting with the operating system. Instead, the target audience I see for these changes is network-centric projects where all the primary developers are running either Linux or Mac OS X on their personal devices, and deploying to Linux servers. If you tell them "You need to make major changes to your project to properly support native deployment on Windows", then they will say "OK, we'll just drop the claim of Windows support, so we're not giving people false expectations" rather than actually making the change. That then excludes a lot of potential contributors from their project (since they need to be able to run Cygwin, WSL, containers or VMs to get a compatible test environment), and it also means folks running Windows based infrastructure can't readily run the service up on an existing system without using like Cygwin, Docker, or the new WSL. However, this view is also why I don't agree with being aggressive in making this behaviour the default on Windows - I think we should make it readily available as a provisional feature through a single cross-platform command line switch and environment setting (e.g. "-X utf8" and "PYTHONASSUMEUTF8") so folks that need it can readily opt in to it, but we can defer making it the default until 3.7 after folks have had a full release cycle's worth of experience with it in the wild. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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