Virtual commands that are parsed to start with "python" are restricted to the list of installed versions of Python -- unless the virtual command allows searching and the Python command has no version specification (e.g.`#! /usr/bin/env python`). "python3" is versioned, so the launcher will not search for it using the default SearchPath path. 

For reference, see maybe_handle_shebang() [1], lines 1265-69:

    command += 6;   /* skip past "python" */
    if (search && ((*command == L'\0') || isspace(*command))) {
        /* Command is eligible for path search, and there
         * is no version specification.
         */

The default SearchPath path includes the py.exe application directory, the process working directory, system directories, and the %Path% directories. This default search path can be made 'safe' via SetSearchPathMode or a registry setting, but doing so just swaps the order to search system directories before the working directory. It doesn't remove the working directory, unlike the safe search used by CreateProcess when %NoDefaultCurrentDirectoryInExePath% is defined. 

I think the implementation of find_on_path() could be improved. It should always try appending .EXE, .COM, .BAT, and .CMD if the bare command isn't found, not just if the command doesn't contain a ".". It's not unheard of to have a name with mulitple dots in it, e.g. "spam4.2.exe". Also, looping over all of the extensions listed in %PathExt% is of doubtful value. We don't call ShellExecuteEx to execute arbitrary file types, such as .VBS, .VBE, .JS, .JSE, .WSF, .WSH, and .MSC.

[1]: https://hg.python.org/cpython/file/v3.6.0b3/PC/launcher.c#l1112