On Thu, Feb 4, 2021 at 1:17 PM Barry Scott <ba...@barrys-emacs.org> wrote:
> Rather than reply point by point I will summarise my input. > Thanks! > I think that utf-8 mode is a great idea. > agreed. > I'm hoping that the solution implemented allows new users to get a great > experience and also that advanced users can get control of the mode. > I think we all agree here. > Personally I'd prefer to have files that I edit to configure python then > registry > keys. Amen! I think that an .INI file in the style that py.exe uses is better then env > var. > Note that the env var is already available, so this is agreeing with Inada Naoki that we should add another way to set it. By "in the style" I assume you mean (from PEP 397): """ Two .ini files will be searched by the launcher - py.ini in the current user's "application data" directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA, %USERPROFILE%\AppData\Local on Vista+, %USERPROFILE%\Local Settings\Application Data on XP) and py.ini in the same directory as the launcher. """ But are you suggesting that the py.exe launcher be used in this case? Or that there'd be two locations searched for an ini file: in the user's "application data" directory and next the python.exe executable ? If so, then yes, I think that would work -- as the various "environment" systems all have copies of python.exe inside their environments, so that would allow per-environment configuration -- which is what I think we need. I'm going to step back a bit from the solution to my ideas for the specification: 1) UTF-8 mode is a global-to-the interpreter setting. So there is no way to have something like a __future__ import that will turn it on for just one module or package. 2) A given system can have any number of different versions (python3.8, 3.9, .. python.org install vs conda install, or python shipped with software, like the ESRI ArcMap) of Python installed, AND potentially any number of environments with a given Python version. 3) A given system can also have multiple users, and each of those may have different needs. With all these different "pythons", many folks probably wouldn't want to have them ALL configured the same way -- even all within a given user's space -- changing the setting to "fix" one application might break others. Python has already had this problem for years: installing / upgrading a package for one app could break other apps. And the solution that the community has converged on is "environments" -- there are various implementations, but they all do a similar thing -- allow multiple configurations of the same Python version on the same system, for the same user. So I think it makes all the sense in the world to have the ability to have UTF-8 mode specific to the environment. Then we have to decide who is in "control" of the utf-8 mode setting? Certainly the end-user should be, and maybe the system administrator should be -- at least for the defaults. But I think the application developer should be able to specify utf-8 mode for a given application, and it should be easy for a relatively naive user to get it as the application developer wants it. Sure, one could write in the Installation instructions that this app will work best under Windows with utf-8 mode turned on, and directions for how to do that, but that might be a bit too easy to miss. So I'd love to see a way to have a pip-installable package that turns on utf-8 mode, so one could simply put it in the application's requirements file, and end users wouldn't have to do anything special, and would simply get the right behaviour with an ordinary install. The only missing piece is how to specify an environment that is configured a certain way. As far as I know, the only thing you can specify for pipenv or virtualenv is a package installable by pip. and I think tha pip will only install things in site-packages -- not "next to" the python.exe file. But I think the site-packages path hasn't been configured yet when this is needed, so that's a trick. So if this config file could be somewhere pip could install it I think that would be helpful. Personally, I'm a conda user, and conda can install files anywhere in the tree -- so I would likely make a conda package to enforce utf-8 mode if this becomes available, so I could put it in my applications' requirements, and know my users will have it turned on when they run my code. - Chris B -- 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/L56VRFKF73L3ZLTZ3PQLTKZK2M24E7TB/ Code of Conduct: http://python.org/psf/codeofconduct/
