On Tue, Feb 2, 2021 at 1:37 PM Barry Scott <ba...@barrys-emacs.org> wrote:
> 2) perhaps UTF-8 mode isn't the only use-case for this -- it would be good > to have a way to have Python startup parameters that are installation / > environment specific -- that could help with other issues with "global" > configuration: PYTHONPATH, PYTHONHOME, PYTHONSTARTUP, other PYTHON* > environment variables. > > Forgive me if I'm miss understanding your position. > > Windows is successful because of its backward compatibility. > That includes big problems with text encoding in the modern world. > > Aside: HTML 5 even has a encoding rule that acknowledges that web pages > marked > utf-8 are really windows USA code page and show how to fall back! > But that doesn't depend ina. system setting does it? So I don't get your point: If you think UTF8 mode is a bad idea, then don't use it. or are you saying it should be turned on for everything on a given Windows system, which also doesn't make sense? > Are you calling env vars global config? > well, yes and no -- a number of systems will set environment variables before they start up, which does allow local configuration. But I can't see how that's practical in this case -- it would require another layer on top of the python executable to set up the environment variables. In the common case, folks have their environment variables set in an initialization file (or the registry? I've lost track of what Windows does these days) so each user has their own set, but for one user, every instance of Python will use the same set. You run some code with Python3.8, then gain with 3.9, then again with a Jupyter notebook running ??, then a virtual environment you've set up for your web app -- all the same set of Environment variables. conda, on the other hand, does set environment variables when you activate an environment, so it could provide a separate set for each environment -- but that would be a conda-specific solution. And I'm not sure that you can have a conda package set them either, so it would need to be a new feature added to conda anyway. 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. > Sure, but it would still be nice to have one fewer quirk to deal with. And this isn't about Windows-specific behavior -- it's about behavior that is potentially different among each instance of Windows. And as a practical matter -- there is far too much Python code out there that does, indeed, ignore the specific reality that not all systems have utf-8 as their default. > 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. > are you suggesting that users will need to hand-edit, and only hand-edit their config file? and that they will be able to figure out how to set the right special code for python 3.9 installed from python.org with a particular virtual environment? even if you ignore virtualenv -- the example you gave would have to be created for three different Pythons, sourced from three different "vendors", and I'd sure hope that they'd have their installer put something in the config for you. > 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. > we already have a default for this thread -- it's UTF8-moe is off.and with backward compatibility, no other option is on the table. I do not advocate a global ini file. I do not think I asked for that. > not global to the system, but global to all Pythons > I'm suggesting a mechanism that is identical to the way the py.exe is > configured. > That's the python launcher?, yes? Forgive my ignorance, but how IS that configured? I do know that it can look at a #! line and start up the appropriate version of Python, but is there any way to have it do any other selection? and how does it / can it be used with virtual environments? > 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. > sure -- it can and it probably does, but it would be good for it not to have to use a different mechanism for this. See above -- environment variables (which already exist for UTF8 mode) may be a fine solution for conda -- not so much for other environment systems. > 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? > I mean where it can be controlled along with the "environment". But that is a trick -- there should be a place outside of a system python install that needs admin privileges. If its an application problem then we already know that its a matter of > coding the encode/decode utf-8 explicitly. > Except that a python application probably uses a LOT of code written by others. And unfortunately, that's why this is an issue at all -- there is code that should use the encoding specified, that doesn't. And that is our of the hands of the user, and out of the hands of the application author. > An app could maybe benifit from a sys.set_default_text_encoding() call. > yes, that's been brought up -- but I think that would be too late for some use-cases, like setup.py files reading the README. (though I suppose setuptools could call it) 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? > I wasn't thinking that there would be a "assume-legacy-windows-encoding" encoding package -- but I see your point. You can't correctly run a package that is expecting system encoding at the same time as one that is not expecting utf-8 defaults at the same time. My thought on that is that we have "packages" and "applications". packages have their dependencies declared internally (in setup.py, or pypackage.toml) -- applications have an external requirements file. So the assume-utf8 package should only be used in a requirements file, not a package's dependencies. And I think that's a helpful level of granularity -- we don't want ALL python code run on a given machine by a given user to be in UTF-8 Mode (or not), and it's not possible to have it be module or package specific, but if it could be application specific, that could be useful. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SDVH4RZ7PCLNGVH4TDLB5ZTI4G5QFMNQ/ Code of Conduct: http://python.org/psf/codeofconduct/
