Improve support for Python 2 and 3 on the same Windows machine

[JustinSlootsky]

With a standard install, when a user has both ArcGIS Desktop and ArcGISPro on their computer, there is no way to associate a .py file with the correct python interpreter because it could be either a python2 or a python3 script.

The standard distribution of python3 for Windows includes a tool py.exe that allows developers to specify which version of python the script runs under by putting "#! python3" or "#! python2" on the first line of the script.  The py.exe is associated with .py files and then it calls the correct interpreter according to the first line of the script.

The Python 3 distribution that comes with ArcGISPro does not include this py.exe executable, and additionally does not register PythonCore into HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE in a manner that would allow a downloaded py.exe to locate the Python 3 interpreter.

If one or both of these items were implemented, it would make it easier for users to work with both Python 2 and Python 3 scripts on our machines:

- distribute py.exe with ArcGISPro and configure it so it can call either Python2 or Python3

- populate the HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore correctly so that a downloaded py.exe will work without additional configuration

[ShaunWalbridge]

The py.exe model works well for environments where there are two distinct Python installations on the machine (one Python 2 and one Python 3), and was an important step in the phased transition between the two versions of Python. In the case of our products, it doesn't sufficiently address the issues of binding to Python across multiple products:

 - Multiple product offerings ship with Python 2.7, such as Desktop, Server, and Background Geoprocessing, all which have claim to the Python 2 slot
 - Multiple product offerings ship with Python 3, such as Pro, Server and Drone2Map which all have claim to the Python 3 slot
 - In the case of Python 3, users can create multiple environments with different requirements and dependencies. Conda doesn't include py.exe in part because the current implementation can introduce cross-environment issues of the kind that environments are designed to prevent. Conda environments require an activation step as they rely on modifying the PATH for the duration of the execution to allow siloed sets of modules and DLLs to co-exist

That precludes us from using the py.exe approach as it stands, but we do want to ensure that all versions of Python can be correctly addressed. For Python 3, the active environment can be addressed by calling the propy.bat script for the particular product. With the next release of the 10.x products, we have also ensured there is a clear mapping for each offering to edit and run each separately:

These values can also be found in the registry, and added to custom handlers to launch an appropriate environment for execution. I know that isn't specifically what you had asked, but hopefully that helps you move forward and feel free to follow up in this idea.

Thanks,
Shaun