On Tue, Feb 9, 2021 at 4:53 PM Christopher Barker email@example.com wrote:
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"?
It makes problem too hard, complex. It leads we can not fix anything at all by Python 3.10. We can add Unix support later if it is really worth enough. It is not backward incompatible change.
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.
When using docker, it's very easy to put an environment variable. You don't need to worry about "it will break existing legacy Python application in same container." You can just create one container for one application. So I don't think it is enough reason to.add complexity.
As I said before, use case of UTF-8 mode is different between Unix and Windows.
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.
Without more concrete idea, such rough lead this thread to maze.
Note that UTF-8 mode must be enabled before any path config on Unix. So it is almost impossible to enable UTF-8 mode using tools like pip.
If your idea is just putting `python.ini` (or `python.cfg`) in bin/ or Scripts/ directory from pip/conda package, I don't think it is just a hack, not a best practice. It will cause file conflict error very easily.