> I think it's MUCH better to have ONE way to do something that works, for Python, on all platforms. That way people that only know one platform can still write and document code that can work on all platforms.
This thread is only for make UTF-8 mode accessible for Windows users,
Well, there has been some talk of adding some of the other configuration options as well. But sure.
because UTF-8 mode helps many Windows users but it is not accessible
enough for Windows users.
It's not just accessibility, but discoverability -- Windows users -- and even more so developers that don't generally use Windows often don't know utf-8 mode exists. That's why I'm pushing for a way to for an application developer to be able to set up their project so that it will run under utf-8 mode everywhere. With only one way, and without having to add Windows specific code or documentation.
As has been discusses, there are very few cases where it would make any difference under Linux (and zero for teh Mac?) -- but why not have "one way to do it"?
Can you provide some realistic use cases where UTF-8 mode helps Unix
users but it is not accessible?
It's not accessible to the application developer. It is to the deployer / devops person. These are often one and the same, but not always.
My major project had exactly this problem -- the bare bones docker images used on the CI (and for deployment) were set up with an ASCII locale (or something like that) -- and our application failed. In the end we figured out how to configure the images for utf-8, but as it happens, I know Python, and don't know much Linux administration, and the linux sys admins didn't know Python much -- so it took a fair bit of back and forth to figure out.
We use conda for CI and deployment -- if I had been able to put a "utf-mode" package in the conda requirements file, we wouldn't have had this issue, and our Windows users (yes we have those too) would also get their systems set up to "do the right thing" without their even knowing about it.
Other folks use pipenv and the like -- it would be helpful to them if they could do the same thing with their requirements files as well.
If not, please focus on helping Windows users.
Honestly, I'm trying to help Windows users here -- see above. Honestly, my Windows users are the biggest problem (they tend to be less tech savvy -- at least I had a linux sysadmin to work with, my Windows users usually are not sysadmins).
And it's not Linux users so much anyway -- it's linux developers that want to support Windows users. Remember back in the day of Python2, where opening a text file and binary file was no different on *nix? There were no shortage of bugs that didn't turn up in code tested on *nix until a Windows user came around -- but at least it was an easy fix -- as 'b' flag,and the ocde would work the same on all platforms.
And in the end, if there is a single solution that can do the same thing in the same way on all platforms isn't that less maintenance and documentation work?
Time is a limited resource. I have no time to discuss about helping
zero Unix users.
By all means -- spend your time on what you think is important. You asked for others' opinions, I've given mine. If you don't agree, so be it.
Thanks for your work on this -- anything you do will be an improvement.
-Chris
--