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/FEGEC5LHV6VJZESMPAJKAJ22C7CHXGV2/ Code of Conduct: http://python.org/psf/codeofconduct/
