> On 10 Jul 2019, at 21:13, Steve Barnes <gadgetst...@live.co.uk> wrote: > > Brett, > > Can I suggest that it might be an idea to add the honouring of PY_PYTHON and > PY_PYTHON2 environmental variables to the help text. This is the missing > piece as far as I am concerned.
I knew about the py.ini but not the env vars - nice to know. Adding the info the help would have helped me. Also you could show the path of the INI file in the help. I had to write code to find the value of "the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA" (from https://docs.python.org/3/using/windows.html#customization <fromhttps://docs.python.org/3/using/windows.html#customization>). Far better to put the path in the help. I tend to avoid env vars on windows as its chunky to work with compared to mac or linux. I wonder if it would be useful to be able to have py.exe update the user's py.ini from the command line? py -3.7 --set-default And be able to see what the defaults are? py --show-defaults Barry > > Steve > > From: Brett Cannon <br...@python.org <mailto:br...@python.org>> > Sent: 10 July 2019 18:41 > To: Steve Barnes <gadgetst...@live.co.uk <mailto:gadgetst...@live.co.uk>> > Cc: Python-Ideas <python-ideas@python.org <mailto:python-ideas@python.org>> > Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not > using pre-releases by default > > Based on the various responses I've seen, one thing I want to make very clear > is the launcher needs to be fast. That means no executing Python code, > minimizing stat calls, etc. > > Also be aware that I'm developing a launcher for UNIX, which puts its own > twist on this whole situation as there's no real registry on UNIX. ;) So that > means there are limited options for making this too fancy. (The UNIX launcher > uses PATH and the file name to determine what versions of Python are > installed.) > > One thing I will say is this issue can be solved manually today: environment > variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the > default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with > `py -3`. Since this discussion is for people installing betas I would assume > those people are also installing new versions of Python, which means you > probably only need to update this once every 18 months once you install the > newest stable feature release. > > On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <gadgetst...@live.co.uk > <mailto:gadgetst...@live.co.uk>> wrote: > My thought is one of: > - if an explicit version is not specified the top (i.e. highest version) > candidate at the call time could be timestamp checked and compared with a > registry or ini file entry - if the entry for that version is missing or has > a different timestamp stored then it could be invoked with --version and the > version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ > to generate or set a stable/unstable flag (and the timestamp). This should be > minimal overhead and would be transparent to the user. > - There could be a --refresh-candidates flag or some such that could run > through each of the possible pythons, or a specified one, using the same > technique to check stability flags and the results saved in the registry and > used - this would be less per run overhead but more manual it could > potentially be added to a post install step in the installer at some point. > - If a metadata flag for the registry could be decided on and honoured by py > & pyw but ignored if missing then a separate utility (possibly pip installed) > could be used to set/unset it again using the detect version string mechanism > or otherwise. (This could possibly even query an online resource to disable > by default unsupported, or known bad if it ever became necessary, versions. > > Any of these approaches would, I believe, address the need for the > maintainers to add metadata to the build, (other than what is already added > to adjust the version string), and would be fast & future proof (addressing > Ben's concerns). > > -----Original Message----- > From: Alex Walters <tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>> > Sent: 10 July 2019 07:23 > To: 'Steve Barnes' <gadgetst...@live.co.uk <mailto:gadgetst...@live.co.uk>>; > 'Python-Ideas' <python-ideas@python.org <mailto:python-ideas@python.org>> > Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using > pre-releases by default > > I have made this suggestion in the past. The response then was that there is > no metadata in the windows install that includes if the release is > development or stable (that information is not stored in the registry). I > was advised to adjust my configuration of the py.exe launcher to set a > different default version. > > I think that's a reasonable stance to take with development versions - they > are intended for testing in specialist situations, so you can expect the > users to take the extra steps to make sure using them doesn't blow up their > world. > > It still would be nice if the registry details of the install had a bool > "stable" field that py.exe could poll. I can't imagine it adds a lot to the > release process, or adds significant complexity to the launcher, and that > negates the need to update the launcher regularly. > > > -----Original Message----- > > From: Steve Barnes <gadgetst...@live.co.uk <mailto:gadgetst...@live.co.uk>> > > Sent: Tuesday, July 9, 2019 1:32 AM > > To: Python-Ideas <python-ideas@python.org <mailto:python-ideas@python.org>> > > Subject: [Python-ideas] Suggestion: Windows launcher default to not > > using pre-releases by default > > > > Currently the py[w] command will launch the latest python by default > > however I feel that this discourages the testing of pre-releases & > > release candidates as once they are installed they will become the > > default. What I would like is for the default to be the highest > > version number of a full > release > > but the user to be able to specify a specific version even if it is a > pre-release. > > > > > > > > The currently py or py -3 would give python 3.7 (if installed) but py > > -3.8 > would > > give the pre-release/release candidate if installed. > > > > > > > > Any thoughts on whether this would be a good idea - I am quite willing > > to undertake the changes. > > > > > > > > Steve Barnes > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/>_______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-le...@python.org > <mailto:python-ideas-le...@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/EDTOY6LYY6BTSPMQSIRS6IUTCLZAJIKI/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/EDTOY6LYY6BTSPMQSIRS6IUTCLZAJIKI/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/>
_______________________________________________ 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/KWWWO6Z4IIUTJMOYQBTLEKQGDX2TLYPX/ Code of Conduct: http://python.org/psf/codeofconduct/
