I'll also mention it's covered in the official docs at https://docs.python.org/3/using/windows.html#launcher.
On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon <[email protected]> wrote: > > > On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes <[email protected]> > 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 would then open a bug report and if you feel up for it open a PR (the > function you want to change is > https://github.com/python/cpython/blob/master/PC/launcher.c#L1398). > > FYI the Python launcher for UNIX already has this in its help output: > https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt. > > >> >> >> Steve >> >> >> >> *From:* Brett Cannon <[email protected]> >> *Sent:* 10 July 2019 18:41 >> *To:* Steve Barnes <[email protected]> >> *Cc:* Python-Ideas <[email protected]> >> *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 <[email protected]> >> 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 <[email protected]> >> Sent: 10 July 2019 07:23 >> To: 'Steve Barnes' <[email protected]>; 'Python-Ideas' < >> [email protected]> >> 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 <[email protected]> >> > Sent: Tuesday, July 9, 2019 1:32 AM >> > To: Python-Ideas <[email protected]> >> > 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/message/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >>
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4TCS6ZOZ2VZYLK2VDNGLYAVBZ6IABDL5/ Code of Conduct: http://python.org/psf/codeofconduct/
