3.10 Additional modules 31 3.10. Additional modules Python Setup and Usage, Release 3.9.5 If a$_{pyvenv.cfg}$ file is found alongside the main executable or in the directory one level above the executable, the following variations apply: The end result of all this is: For those who want to bundle Python into their application or distribution, the following advice will prevent conflicts with other installations: These will ensure that the files in a system-wide installation will not take precedence over the copy of the standard library bundled with your application. Otherwise, your users may experience problems using your application. Note that the first suggestion is the best, as the others may still be susceptible to non-standard paths in the registry and user site-packages. Changed in version 3.6: Deprecated since version 3.6: Modules specified in the registry under$_{Modules}$ (not$_{PythonPath}$ ) may be imported by$_{importlib.machinery.WindowsRegistryFinder}$ . This finder is en- abled on Windows in 3.6.0 and earlier, but may need to be explicitly added to$_{sys.meta_path}$ in the future. Even though Python aims to be portable among all platforms, there are features that are unique to Windows. A couple of modules, both in the standard library and external, and snippets exist to use these features. The Windows-specific standard modules are documented in mswin-specific-services. • Adds$_{pythonXX.zip}$ as a potential landmark when directly adjacent to the executable. • Adds$_{._pth}$ file support and removes$_{applocal}$ option from$_{pyvenv.cfg}$ . • If you cannot use the previous suggestions (for example, you are a distribution that allows people to run $_{python.exe}$directly), ensure that the landmark file ($_{Lib\os.py}$ ) exists in your install directory. (Note that it will not be detected inside a ZIP file, but a correctly named ZIP file will be detected instead.) • Clear and/or overwrite PYTHONPATH and set PYTHONHOME before launching $_{python.exe}$from your application. • If you are loading python3.dll or python37.dll in your own executable, explicitly call Py_SetPath() or (at least)$_{Py_SetProgramName()}$ before$_{Py_Initialize()}$ . • Include a$_{._pth}$ file alongside your executable containing the directories to include. This will ignore paths listed in the registry and environment variables, and also ignore$_{site}$ unless$_{import site}$ is listed. • If Python can’t find its home and there are no registry value (frozen .exe, some very strange installation setup) you get a path with some default, but relative, paths. • When Python is hosted in another .exe (different directory, embedded via COM, etc), the “Python Home” will not be deduced, so the core path from the registry is used. Other “application paths” in the registry are always read. • When running python.exe , or any other .exe in the main Python directory (either an installed version, or directly from the PCbuild directory), the core path is deduced, and the core paths in the registry are ignored. Other “application paths” in the registry are always read. • If$_{home}$ is an absolute path and PYTHONHOME is not set, this path is used instead of the path to the main executable when deducing the home location.