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> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <gadgetst...@live.co.uk>; 'Python-Ideas' <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> > Sent: Tuesday, July 9, 2019 1:32 AM > To: Python-Ideas <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 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/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/ Code of Conduct: http://python.org/psf/codeofconduct/
