Currently the launcher will give an error message if a matching python is not found when using the -x.y-bits notation on the command line however the user has to know which python(s) they have available.

When some pythons have been installed all user and some specific user only the individual user may well not know which pythons they have available.

I would like to suggest adding to the command line -l and -L options for list and Long list options. Each option would populate the installed_pythons list and then

-l print the list of usable -x.y-bits options currently available.
-L print the list with the paths of the executable files.

In either case the launcher should terminate after printing the list.

This would be useful for deciding which python(s) to test with and for producing a list to be able to deploy critical updates to all installed pythons.

The problem with taking more command line options is that we prevent real Python from ever using those options (or we end up with obscure rules like the "-3" one).

Perhaps you'd be interested in using/contributing to my pep514tools project: https://github.com/zooba/pep514tools ? Because it doesn't have to imitate python.exe, it can have its own command line options, and I'd be totally happy for the __main__.py to be filled out.

@steve.dower I did check and none of the currently supported pythons us -l or -L and have implemented it with -list and -long-list but I do appreciate your point that someone might come up with a use for all of these flags in a future version of python.

How about dropping the short flags, (-l & -L), and making the long flags more launcher specific, i.e. --launcher-list and --launcher-list-paths spring to mind.

I really do think that this change would be really useful, e.g. in the short form to generate a list of installed targets that might all need a specific library updated or to create one venv for each installed target, the long version has already helped me out spotting where a python that I was not expecting had been added to the registry.

I'll also take a look over on pep514tools to see if there is anything I can do to help there.

py already has the -number option space. To avoid conflict, use -0 (zero). I think only one option is needed -- print 'x.y path' for each binary it can find and run. 'x.y' should be the exact option needed to start the particular binary.

This enhancement would enable IDEs to much more easily offer 'Run with x.y'. It also would make bpo-30405 (register locally built binaries) more useful.

@terry.reedy - Very good points and I like the shortness of -0 note that there is already an accepted change to allow -x.y-64 to specifically require the 64 bit versions so we don't need the complex logic to distinguish cases where -x.y will run 32 bit because there is no 64 bit verses -x.y will run 64 bit and -x.y-32 will run 32 bit so I haven't implemented that complex logic.

I have put a tab between the run flag and the path as I find that is easier to detect than some number of spaces.

Found that I needed to move the test for -0 nearer the top as 0 is a potentially valid version specifier, (isdigit).

Also modified the "not found" message to mention -0 as an option for discovery.

I'm -0 on the "-0" option, but I think printing the list of registered Python installations would be useful in the --help text and when the launcher fails to find a requested version.

I agree with printing discovered interpreters in help text - not a fan of the -0 option.

IDEs should probably go directly to the registry to discover Python installations (or use pep514tools), since the launcher will only launch a subset of them (i.e. per-user overrides per-machine, non-PythonCore are excluded). Relying on py.exe being available (it's optional), being in a certain location (there are multiple possibilities), and having parseable output (which is a *big* implicit guarantee) doesn't make me comfortable.

Latest push still has -0 and -0p options for explicit discovery but also defaults to displaying the list if the requested version is not found. (As well as the default python being marked with a trailing * - I have also removed the less than helpful "default python not found when no pythons were found, (very much a corner case).

I feel that the help text is a little on the long side to include the list as well in response to --help so only added it to match not found use case.

I also feel quite strongly that the option for displaying the discovered paths saves a step or two in locating problem installations.

I'm also not a fan of the -0 option. I'm OK with the ability to list available interpreters, but there's nothing about -0 as an option that says to me that's what it's for.

I'm not a huge fan of including the list in the standard help, as py -h already generates the launcher help followed by the Python help and so is pretty verbose.

Maybe just bite the bullet and use "py --list"? It doesn't clash with any existing Python argument, and the core interpreter doesn't typically use long options, so we're probably reasonably safe grabbing --list.

--list and --list-paths added back in following review by paul.moore.
The short options -0 & -0p left in as short forms.

Note that the -0, --list, -0p & --list-path options will only be invoked if they are the only argument to py.exe this mirrors the original implementation of --help.

If this option is added into the py launcher it will make it usable for a multipy script/utility that would call py -0 to get a list of installed pythons and then call it for each of the returned versions with the remaining parameters.

I personally would find this very useful for things like:

multipy -m pip install --upgrade matplotlib

so as to install upgrades to all of the system pythons.

New changeset 5b8f972 by Steve Dower (Steve (Gadget) Barnes) in branch 'master':
bpo-30362 : Add list options to launcher. (bpo-1578)
5b8f972

Thanks, Steve!