We Keep Coding

Prevent a Python-embedded to look in my default path C:\Python38 for modules

I'm using Cython in --embed mode to produce a .exe. I'm evaluating the Minimal set of files required to distribute an embed-Cython-compiled code and make it work on any machine. To do this, I only copy a minimal number of files from the Python Windows embeddable package.
In order to check this, I need to be sure that the current process I'm testing doesn't in fact use my system default Python install, i.e. C:\Python38.
To do this, I open a new cmd.exe and do set PATH= which temporarily removes everything from the PATH. Then I can test any self-compiled app.exe and make sure it doesn't reuse C:\Python38's files under the hood.
It works, except for the modules. Even after doing set PATH=, my code app.py
import json
print(json.dumps({"a":"b"}))
when Cython---embed-compiled into a .exe works, but it still uses C:\Python38\Lib\json\__init__.py! I know this for sure, because if I temporarily remove this file, my .exe now fails, because it cannot find the json module.
How to completely remove any link to C:\Python38 when debugging a Python program which shouldn't use these files?
Why isn't set PATH= enough? Which other environment variable does it use for modules? I checked all my system variables and I think I don't find any which seems related to Python.

Python has a quite complicated heuristic for finding its "installation" (see for example this SO-question or this description), so probably it doesn't find the installation you are providing but the "default" installation.
Probably the most simple way is to set the environment variable PYTHONPATH pointing to the desired installation prior to start of the embedded interpreter.
By examination of sys.path one can check whether the correct installation was found.

Thanks to #ead's answer and his link getpath.c finally redirecting to getpathp.c in the case of Windows, we can learn that the rule for building the path for module etc. is:
current directory first
PYTHONPATH env. variable
registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python or the same in HKCU
PYTHONHOME env. variable
finally:
Iff - we can not locate the Python Home, have not had a PYTHONPATH
specified, and can't locate any Registry entries (ie, we have nothing
we can assume is a good path), a default path with relative entries is
used (eg. .\Lib;.\DLLs, etc)
Conclusion: in order to debug an embedded version of Python, without interfering with the default system install (C:\Python38 in my case), I finally solved it by temporarily renaming the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python to HKEY_LOCAL_MACHINE\SOFTWARE\PythonOld.
Side note: I'm not sure I will ever revert this registry key back to normal: my normal Python install shouldn't need it anyway to find its path, since when I run python.exe from anywhere (it is in the PATH for everyday use), it will automatically look in .\Lib\ and .\DLL\ which is correct. I don't see a single use case in which my normal install python.exe wouldn't find its subdir .\Lib\ or .\DLL\ and requiring the registry for this. In which use case would the registry be necessary? if python.exe is started then its path has been found, and it can take its .\Lib subfolder, without help from registry. I think 99,99% of the time this registry feature is doing more harm than good, preventing a Python install to be really "portable" (i.e. that we can move from one folder to another).
Notes:
To be 100% sure, I also did this in command line, but I don't think it's necessary:
set PATH=
set PYTHONPATH=
set PYTHONHOME=
Might be helpful to do debugging of an embedded Python: import ctypes. If you haven't _ctypes.pyd and libffi-7.dll in your embedded install folder, it should fail. If it doesn't, this means it looks somewhere else (probably in your default system-wide Python install).

What is the advantage of "#!/usr/bin/env python" in the shebang rather than just calling the "#!python" interpreter?

I understand the difference between starting a python script like:
#!/usr/bin/env python
or
#!/usr/bin/python
From what I understood, just executes python as we would do in our shell, so it looks in $PATH. The second one is not a fixed path, which has the inconvenient that in a different system the python interpreter might be located in another path.
My question is, why do we need env? Why can we just do:
#!python
This works perfectly fine in my computer? Is there a reason to prefer calling env?

Short answer:
This depends on the shell. in bash #!python will just be ignored and you have to use #!/usr/bin/env python. zsh on the other hand seems to be able to handle #!python.
The long answer (for bash):
let's imagine your python file is named 'tst.py'
and has following contents
#!python
import sys
print(sys.executable, sys.version)
then you can always type
python tst.py
The first line is completely irrelevant and is not even looked at.
However if you do following (for example on linux)
chmod +x tst.py
./tst.py
Then the first line is looked at to determine which interpreter shall be used (bash, perl, python, something else?) and here at least for my OS (ubuntu) and my shell (bash) an absolute path is required for the executable name (e.g. /bin/bash, /bin/python, /usr/bin/env)
If I call ./tst.py on my ubuntu machine I get
bash: ./tst.py: python: bad interpreter: No such file or directory
Special case Windows, when typing tst.py or clicking on a python script.
If you're on windows, the line is looked at, but even if it is wrong a default python interpreter will be used. On Windows, this line could be used to select explicitly python2 or python3 for example.
Windows uses file type associations to determine which executable to call for which suffix. for .py files (python 3.x is installed) this is normally py.exe which is an executable located in the system path, that will just call a python interpreter. depending on installed versions, the shebang line and environment vars, that might indicate a virtualenv
Addendum:
The first line is interpreted by the shell or in the windows case by py.exe.
It seems bash requires absolute paths for command, whereas zsh accepts relative paths as well.
So for zsh only
#!python
works perfectly well whereas bash requiers absolute paths and thus the trick with the env command
#!/usr/bin/env python
For scripts that shall be executed by a cronjob it's best to hardcode the path of the python executable as PATH is rather minimalistic for cronjobs, so there it's best to have something like
#!/usr/bin/python3.5
or
#!/home/username/myvirtualenv/bin/python

Each Python script is written with a particular version of Python in mind. If the shebang is #!/usr/bin/env python, that puts the version used under the control of the individual caller, whose PATH may not provide the right version.
#!/usr/bin/python is a little better, as it puts the decision in the hands of the script itself. However, the script author doesn't necessarily know where the correction version of Python is on your system, so it still may not work.
The solution is to specify the correct location on your system when you install the module or script. The Python installer (pip, etc) will, at that time, rewrite any shebang containing the word python (#!python being the minimal such shebang) to the path specified by the installer.
Now when you run the script, it will point to the correct path that you have already provided, without being subject to runtime PATH lookup that could choose the wrong version.
Note that #!python is not meant to be used as-is, though for various reasons it might work for you. It's is a means towards making sure the script gets a fixed, absolute path to the correct interpreter. #!/usr/bin/python is also subject to install-time replacement, so may serve as a usable default.

Why would I add python to PATH

I am beginning to look at python, so when I found a tutorial it said that the first thing to do would be to download python from www.python.org/downloads/
Now when I downloaded python 3, I then started the installation and got to
Why would I want to "Add Python 3.5 to PATH"? What is PATH? Why is it not ticked by default?

PATH is an environment variable in Windows. It basically tells the commandline what folders to look in when attempting to find a file. If you didn't add Python to PATH then you would call it from the commandline like this:
C:/Python27/Python some_python_script.py
Whereas if you add it to PATH, you can do this:
python some_python_script.py
Which is shorter and neater. It works because the command line will look through all the PATH folders for python and find it in the folder that the Python installer has added there.
The reason it's unticked by default is partly because if you're installing multiple versions of Python, you probably want to be able to control which one your commandline will open by default, which is harder to do if both versions are being added to your PATH.

In addition to what #SuperBiasedMan stated, you can edit your PATH in Windows by hitting Start > Run, then type sysdm.cpl.
From there, navigate to Advanced tab and then hit Environment Variables.
In the lower section, where it says 'System variables', find the one named PATH and double click it. Note that it would be easier to copy and paste it to a notepad or something. The separator as you can see is a semi-colon.
Any path that you add to this variable, will be looked when you type any command in a cmd window or through the 'Run' command line.
That's the same concept as in Linux, I just pointed out how it can be edited.

This shows the way if you haven't add python to PATH(By the way, the python.exe is in my Python directory)
This is the way if you add python to a PATH

Python Installation Location (Windows)

I need to find out if there is Python installed on the computer.
My specific issue is that I am distributing a program that comes with its own interpreter + standard library (the end-user may not have Python). In the installation, I am giving the option to use the user's own installed Python interpreter + library if they have it. However, I need the location of that. I can ask the user to find it manually, but I was hoping there was an automatic way.
Since my installer uses my included interpreter, sys.prefix refers to the included interpreter (I know this because I tried it out, I have Python 2.7 and 3.3 installed).
I also tried using subprocess.call: subprocess.call(['py', '-c', '"import sys; print sys.prefix"']) which would use the standard Python interpreter if there was one, but I'm not sure how to capture this output.
Thus, are there any other ways to find out if there is a default Python version installed on the user's computer and where?

Actually, in the light of my other answer, an even better way to find the Python installation directory would probably be to check the Windows registry, since the Python installer places some information there.
Take a look at this answer and this Python module.

Some users might have placed their local Python directory into the system's PATH environment variable and some might even have set the PYTHONPATH environment variable.
You could try the following:
import os
if "python" in os.environ["PATH"].lower():
# Confirm that the Python executable actually is there
if "PYTHONPATH" in os.environ.keys():
# Same as in the last if...
As for the subprocess.call(...), set the stdout parameter for something that passes for a file object, and afterwards just .read() the file object you gave to see the output from the call.

How to make newest version of Python the default or first in path

I have installed a new version of Python, so I want to make sure when Python is invoked that version is first in my path. So, now on my 'C' drive I have "Python27" and "Python32" (old and new version, respectively).
When I type "python" in the command line I get "Python 2.7". Using control panel I have changed the "path" and "pythonpath" user variables (from 'C:\Python27' to 'C:\Python32') and to be sure I have reload the system. It still does not work. Does anyone have any idea how I can force the system to use the new version of Python?
ADDED
May be this is important. When I go to the 'Python32' directory and type in command line 'python', I do get the new version.

I know you say you've updated %PATH%. However, from the description of the symptoms it is almost certain that c:\Python27 still appears on the %PATH% instead of (or before) c:\Python32.
To diagnose, start cmd.exe and type set. Then locate PATH and see what Python directories it contains and in what order.

Personally, I put the dirs to all installed Python versions in %PATH%, but changed the executable names for all but the 'default' version. E.g., I have a C:\Python26\Python.exe, C:\Python27\Python27.exe and a C:\Python32\Python32.exe. This way I can easily start any version from the command line.