While working on patches for python, typing path\repository\PCbuild\win32\python-d.exe is an error-prone pain.  I would really like to be able to run locally built binaries with py.    Could pcbuild/build.bat register binaries that it successfully builds?  And then print the -x.y option needed for py?  

#30362 would nicely complement this issue.

I'd be wary of leaving out of date registry entries around. Maybe make it a separate script (or part of build.bat but requiring a command line flag to request it)?

Alternatively (or as well) we could have a cleanup command that removes registry entries for working builds that are no longer wanted. Of course you can handle this by manually editing the registry - but the same could equally be said of the original request...

Hmm, thinking a bit further, are you just suggesting registering the build as -3.7? What if I were to build the 3.6 branch? Would that overwrite my "real" 3.6 registry entries?

As things stand, the launcher can only register two copies of Python for any given minor version (one 32 bit and one 64 bit). So this would only really be useful for trunk (and for builds of versions where you don't already have the release version installed).

I presume there is already a dead registry entry problem if someone simply deletes the pythonxy directory.  (I know, very bad idea.)  On the other hand, deleting a git repository directory *is* the thing to do.  While listing entries and paths, py could check that the path exists and delete the registry entry if it does not.

I have no idea how easy it would be to expand to more than x.y and x.y-32.  For myself, this is not immediately an issue as I install 64 bit versions and build the default 32 bit debug versions.

Terry: Is python.bat sufficient for your uses?  It's created by PCbuild/python.vcxproj, and always points to whatever interpreter you built last.

If it's not enough, maybe it could be extended to invoke any already-built interpreter?

From a couple of tests, the local python.bat should be satisfactory for most of my current uses.  Being part of a #30362 listing would be nice, but I don't often change my set of build binaries.

I am most interested in making py.exe follow PEP 514 and look up tags. Given this, we could register builds as "PythonCore\Dev" and then use "py.exe -dev" to run the most recent build. At worst, we only have one lingering registration (and a positive - it would be available to any tools that follow PEP 514 to locate Python installs).

Alternatively, it could go to "PythonDev\..." and we have another way to look it up.

The default tags used to register Python deliberately match the py.exe launcher (e.g. "3.6" and "3.6-32", though it now also supports "3.6-64" to prevent fallback to the 32-bit interpreter). This should make it *nearly* a non-issue to change the launcher to look up Tags rather than versions. Probably needs a prototype to see just how bad it would be - I haven't had time to do it.

Supporting PEP 514 tags is an interesting idea, but maybe you could go into more detail about what you have in mind. Are you thinking of using the SysVersion, SysArchitecture, and [Windowed]ExecutablePath fields where available instead of parsing version tags and assuming "python[w]/exe"? How would the expansion of candidate installations affect virtual "python" shebangs and command-line arguments such as -3.6-32? If there are several 32-bit 3.6 installations, which one wins?

The PY_PYTHON environment variable could support qualified tags such as "PythonDev/3.6-32". However, arbitrarily named tags can't be supported on the command line without introducing an option reserved for the launcher. It could look for an `X PY_PYTHON` option such as `py -X PY_PYTHON=PythonDev/3.6-32`. That's a bit verbose, but simpler than `cmd /c "set PY_PYTHON=PythonDev/3.6-32 & py`.

My thinking was basically to use an algorithm like this:

    if sys.argv[1].startswith('-'):
        company, _, tag = sys.argv[1][1:].rpartition('\')
        if company:
            # look for Tag under Company
        else:
            # look for tag under PythonCore, then other companies

We'd need special handling for Python versions before 3.5 (because of the "-32" change), and possibly for the "-64" suffix as well. But in general, for unique tags you should only have to specify the tag, and the company is used to disambiguate/filter if desired.

SysVersion/SysArchitecture/Version are purely informational according to the PEP (and certainly by intent, if the wording happens to be unclear).

The existing code can be adapted to generalize support for version-number tags, i.e. X.Y[-32|-64]. locate_all_pythons() would need to search every company key to add executable installations that use version-number tags to the installed_pythons array. Whether a tag uses a -32 or -64 suffix is immaterial because the launcher calls GetBinaryType on the executable. A "Company" field would be needed in INSTALLED_PYTHON to allow narrowing a search, such as `py PythonCore\3.6-32`. Also, compare_pythons() would need to order PythonCore ahead of other companies in the installed_pythons array to meet the precedence requirement. 

A new find_python_by_tag(tag, company) function could implement finding non-version tags. It would return the first executable Python installation that exactly matches the tag. find_python_by_tag() would be called in process() in between validate_version() failing and skipping past the command-line options.

(BTW, skipping past the options doesn't work right for options that take an argument such as -X and -W. The launcher sees the optional argument as the script. At best the _wfopen_s call fails, and then it falls back on executing the default Python.)

It's conceivable to generalize maybe_handle_shebang and parse_shebang to support companies in virtual shebangs such as #!/usr/bin/ExampleCorp/python3.6, but that's beyond the intention of the built-in virtual shebangs. They were added to support Unix shebangs in cross-platform scripts. Defining custom commands in py.ini would be a better approach for something like this.

Steve, I gather you don't think it's a problem to use arbitrarily named tags on the command line. The launcher shouldn't look for an "h" tag for `py -h`, so how about using a list of existing command-line options that will never be looked up as unqualified tag names (i.e without a company)? In that case such names would need to be used in -Company\Tag form.

> Steve, I gather you don't think it's a problem to use arbitrarily named tags on the command line. The launcher shouldn't look for an "h" tag for `py -h`

Sure, we can reserve some tags - the -x/y syntax would let you refer to a conflicting one. But other than PythonCore\x.y for (x, y) <= (3, 4), there shouldn't be any need for version or binary checks. Those were needed because we didn't write correct tags, but as of Python 3.5 we write good tags and PEP 514 essentially requires it.