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).

Is there a way to use MinGW without changing Path variable?

So I recently started learning C, and right after i installed the gcc compiler, I realized that the path had to be set to the compiler for me to use it through the cmd prompt.The problem with that is I am doing python as well as C at the same time, and both of them require the Path variable to be set to something specific. So I guess i could change the Path every time I run a specific language, but I was wondering if there is an easier way to do this.
Thanks in Advance

The easiest way add both passes to path variable is to run setx command.
setx path "%path%;x:\path\to\python;\path\to\gcc"
This will take effect only for console session (Thx #Yunnosch for pointing this).
To make the new path really permanent consider downloading and running pathhman.exe
See https://www.windows-commandline.com/set-path-command-line/

I never set the PATH for an individual language.
I use MinGW-w64 GCC either from an IDE like Code::Blocks (see http://winlibs.com/ for instructions to add seperate win32 and win64 GCC to Code::Blocks), or from MSYS2, where I have a .profile script in my home folder setting environment variables like PATH. This way I even have different MSYS2/MinGW combinations on the same system.

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 is not recognised as an internal or external command [duplicate]

This question already has answers here:
"python" not recognized as a command
(14 answers)
Closed 2 years ago.
This is a really annoying problem. I've prowled the web for solutions, but all I found was tips about changing the PATH variable, which I did, of course. My Python install directory is C:\Python27. It' a 32 bit version. Whenever I type python in the command prompt, it says that it isn't recognised as an internal or external command. Currently, my PATH variable is set to C:\Python27;C:\Python27\Lib\site-packages\;C:\Python27\Scripts. Anyone has any ideas? I run Windows 7 by the way (64 bit). I'm pretty desperate. Heck, if nothing works I guess I'll try dual-booting Linux and Windows 7...

Just adding the Python path and trying again worked for me (without reboot).
MS-dos command for Python 2.7:
set PATH=%PATH%;C:\python27\
MS-dos command for Python 3.3:
set PATH=%PATH%;C:\python33\
(check if that is the folder where you installed Python).

Quick fix: May not be the most elegant or long term fix but if you are really frustrated and just want to get it to run, just copy paste the python.exe file to your current directory. This worked for me.

After adding the python folder to the system PATH variable, you should reboot your computer.
Another simple solution is: create a shortcut of the python.exe executable (probably it is in C:\Python27\python.exe, or similar) in a place like C:\Windows\system32 (that is, a place that already is listed in the PATH variable). The name of your shortcut should be python (maybe python.exe should work too). I mean, it can't be python - shortcut or similar, for your purposes.
To see the contents of the PATH variable, go to the cmd and enter set PATH.

After changing the PATH variable in windows, you need to reboot your system before it takes effect.
Edit: As stated by #tdelaney, only a restart of cmd.exe should be required. This is true atleast for Windows 7 64bit.

In your PATH have you got a leading space before your Python path?
For example:
"C:\somedirectory\bin; C:\Python27;C:\Python27\Lib\site-packages\;C:\Python27\Scripts"
If you have a leading space between path's "ry\bin; C:\Pyt", it won't work and is usually the cause for this type of issue.

When installing, there is a checkbox that is by default not selected, but it asks to add python to the environment variable. Re-install and check that box.
I'd rather the installer do it than struggle in the weeds myself.

Okay, as you said your Python install directory is C:\Python27, open my computer, then open c: drive,
if you don't see "Python27" named folder there then try to search it using search option, (in my case i found it in old.window folder, don't know how it moved there) cut and past it in c drive along with folders like, program files, user etc... , now open cmd and type python and hit enter to check if it is working now,

This is only a partial answer, but I found (repeatedly) that I'd have similar issues when I would use the gui installer and not go through the custom setup.
Using the custom setup option, then using the same settings, the "install for all users" (that then installs to C://python.version/blah instead of the user based default structure) WOULD allow the installer to setup PATH correctly.

Switch python distributions

I have a MacBook Pro with Snow Leopard, and the Python 2.6 distribution that comes standard. Numpy does not work properly on it. Loadtxt gives errors of the filename being too long, and getfromtxt does not work at all (no object in module error). So then I tried downloading the py26-numpy port on MacPorts. Of course when I use python, it defaults the mac distribution. How can I switch it to use the latest and greatest from MacPorts. This seems so much simpler than building all the tools I need from source...
Thanks!

First of all, add the MacPorts path (/opt/local/bin) to your $PATH. In .bashrc (or whatever shell config file you use):
export PATH="/opt/local/bin:${PATH}"
If you have multiple versions of Python installed via MacPorts, and/or want to easily switch between the MacPorts and Apple distributions, you can install the python_select port as well.
Also note that the MacPorts version of Python 2.6 is installed into /opt/local/bin/python2.6, so to use that interpreter, you'll have to do one of three things:
Start the interpreter using python2.6 (not just python).
Set up a shell alias so that python calls python2.6 (alias python=python2.6).
Manually set up a symlink from /opt/local/bin/python -> /opt/local/bin/python2.6.
Use python_select to set the Python used by calling python.
Options #3 or #4 are probably the best bet.

You need to update your PATH so that the stuff from MacPorts is in front of the standard system directories, e.g., export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin/:$PATH.
UPDATE: Pay special attention to the fact that /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin is in front of your old PATH value.

The existing answers are quite useful, but I noticed that neither of them spell out how to make the change stick. If you're not familiar with the unix command line this might be important.
First, and explanation: In unix based operating systems, important configuration information in the shell is stored in things called environment variables. The environment variable called PATH directs your shell to a list of places to look for programs. When you type a command, it starts at the leftmost end of the PATH variable, and looks in that folder for the program you tried to run. If it finds it, it runs it; else it looks in the next folder. When you have multiple versions of the same program installed, you can use the PATH variable to give one precedence.
To make use of this, put the folder with the shiny new version in front of the path, like this:
PATH=/opt/local/bin:/usr/bin:/usr/local/bin
To make this change in a single version of your shell, you can type
export PATH=/opt/local/bin:/usr/bin:/usr/local/bin
To make the change in every shell you open, you need to instruct your shell to set this variable every time it starts. There is a file called .bashrc, and another one called .bash_profile that bash will read when it starts up. The .bashrc file is generally used to contain instructions for all shells, and .bash_profile is used to contain instructions only for interactive shells. So, to make this change stick, you can edit /Users/yourname/.bashrc to include a line like this:
export PATH="/opt/local/bin:$PATH"
What that does is add /opt/local/bin to the front of the path variable while leaving the rest of the path alone. If that change doesn't seem to work, you will need to either ensure .bashrc is getting called by adding source $HOME/.bashrc to your .bash_profile script, or just move the necessary line into .bash_profile.