The Windows getpath implementation gained the ability to find and read a sys.path file to skip reading the registry.

While the name is cute, it really ought to start with a leading underscore (i.e. "_sys.path") to indicate that it is very at-your-own-risk. The docs should be updated to indicate that its behavior may be changed in later versions of Python (though it's guaranteed to only change backwards-compatibly for 3.6).

Since the file is only used with a specific installation of Python (specifically the embedded distro), this shouldn't be an issue as nobody is meant to upgrade Python without removing/replacing this file.

I don't want to start a bike-shedding discussion but how about a name that can't be confused with a module and attribute? It's hard to distinguish between sys.path and sys.path in a discussion. How do you like the idea of a file name like __syspath__.path? __omitregistry__.path is even more search engine friendly.

Part of the reason it was so cute is that it directly specifies the contents of sys.path. But I like __syspath__.path (I'm scared of making it a ".ini" because I don't want to parse a more complex format).

If this is only for the use case of embedded distribution we are now only to steps away to provide a easy custom shipping of applications for Windows.

1. Take the file name of the executable to load a custom EXECUTABLENAME.path file
2. Allow to specify a main to be executed or a pyz zipapp to be run with the -m switch. Or simply use first line of the path file if it contains "-m myapp".

With this by only renaming the python.exe and having a simple text file with the information, custom applications distribution can be done.

Sorry, I know not directly related to this.

You can actually handle this already, with a simple wrapper program (based on the one in PC\WinMain.c):

/* Minimal main program -- everything is loaded from the library. */

#include "Python.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int wmain()
{
    wchar_t **myargv = malloc((__argc + 3) * sizeof(wchar_t*));
    int i;
    myargv[0] = __wargv[0];
    myargv[1] = L"myapp.zip";
    for (i = 1; i < __argc; ++i) {
        myargv[1+i] = __wargv[i];
    }
    myargv[1+i] = 0;
    return Py_Main(__argc+1, myargv);
}

This injects your application name "myapp.zip" as the first argument and then calls the Python main interpreter. Run this with a conventional embedded Python, and you have a standalone application.

You can easily tidy the above sample up (it's just a quick hack) to make it generic by working out the name of the zipped Python application from the exe name.

But thanks for the idea - I hadn't really thought about doing something like this until you prompted me to investigate.

I like it. Making the name match the exe name should have been obvious, and if nobody is opposed to simply aborting on unsupported syntax (i.e. imports other than site) I don't actually mind making it .pth.

It's a separate idea, but what if the presence of a __main__.py file caused that file to always run and every argument gets passed to that instead? The purposes seem separate enough to use two files. And we could implement that part easily enough in PC/WinMain.c, as Paul suggests.

Both of these options are fairly aggressive wrt other command line options (i.e. how do you specify unbuffered IO? how do you set the hash seed?), but the point is really that you wouldn't use them with these options - if you don't want to build your own main() function, the defaults should be good enough.

I'd prefer not to hard code __main__.py, as I'd quite like to be able to have a number of copies of the executable, each running its own script. (I foresee putting all my little Python utility scripts in a directory with a Python installation and a set of launchers).

BTW, see https://github.com/pfmoore/pylaunch for a very quickly put together, but working, prototype. Whatever the conclusion here, I'll probably continue working on this. Unless the embedded python.exe completely subsumes the functionality :-)

New changeset 7b47c98f24da by Steve Dower in branch '3.6':
Issue #28137: Renames Windows path file to ._pth
https://hg.python.org/cpython/rev/7b47c98f24da

Decided to go with "DLLNAME._pth" or "EXENAME._pth", since using ".pth" with "import site" causes files to be reevaluated.