Windows is successful because of its backward compatibility.
That includes big problems with text encoding in the modern world.
But it is a Windows problem only.
I write code accepting that unix (*BSD, Linux), macOS and Windows have unique quirks.
To believe that if you ignore that reality is not a path that leads to happiness.
I'd suggest that you could have a %LOCALAPPDATA%\python.ini
But what happen if user installed Python from python.org and Python from conda?User may have two or more Pythons having the same version.
and different environments, be they conda environments, pipenv, what have you.
Apple showed the way by using reversed FQD's.
Further we would need to support multiple versions of python from the same org installed side-by-side.
Structure the .ini so that it has default settings and version specific settings.
This would be pretty painful to manage -- it's a "bad idea" to have a single configuration file that is being managed and updated by any number of different tools. And those tools are managed by different groups of people.
Why would *tools* be messing with my personal config file?
No *tool* messes with py.exe config that I know of.
And this would be VERY hard for end users to manage -- as people installed and uninstalled python versions and environments, they would get a very, very messy global ini file.
End users are best served with good, practical defaults. Choosing those defaults is very hard
which is the point of this thread.
I do not advocate a global ini file. I do not think I asked for that.
I'm suggesting a mechanism that is identical to the way the py.exe is configured.
Also: "conda python" is not necessarily any different than
python.org python -- it's generally built exactly the same way -- the only difference is how it's installed.
A distro will often patch in distro specific changes.
If conda needs to be configure independently from
python.org kits this is an obvious requirement.
So it would be much better for the config file to be located inside the Python installation: essentially a 1:1 relationship between the python executable and the config file. So you know for sure that if you fire up the python you are intending to, you will get the configuration that comes with it.
You mean where it may well not be editable without admin privs?
That is a bad thing surely?
[3.8-64]
utf8-mode = false
The key issue here is that the configuration is not "version number specific" -- it's (or should be) application specific. And Python has had that issue for ages: as a run-time system (for lack of a better word), each application needs a different set of packages in various versions. And that's been addressed with with "environments" of various sorts. So it would be good to leverage that, and have a config file that goes right along with the environment systems: i.e. it's part of that particular Python install,
If its an application problem then we already know that its a matter of coding the encode/decode utf-8 explicitly.
An app could maybe benifit from a sys.set_default_text_encoding() call.
But if its package by package that is far harder problem to solve.
C:\> pip install assume-utf8 assume-legacy-windows-encoding
How does that get resolved?
And ideally, it could be installed with pip somehow, so that an application could specify a python configuration along with its package specifications.
You can only do that for things that pip installs as runnable programs right?
And we would need to add the ability to set the encoding assumption in setup.py.
Barry
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython