Windows's _sys.path file (being renamed from sys.path in b1) currently disable the initial "import site; site.main()" call. However, there are legitimate cases where you may want to opt-in to this while still controlling the search paths. We should support "import site" as a line in this file that indicates that Py_NoSite should *not* be set. We deliberately do not want arbitrary code execution from this file - there's a reason it's '.path' and not '.pth' (While I or someone else is here, we should also handle blank lines and lines starting with '#' specially, so that files can be formatted more nicely.)
But this is nearly the same as a *.pth file. Using the same logic and extension then does not confuse more users. Why not doing the same as with a .pth file? Using something like a _sys.pth file if it is there it will be used for path handling. In all cases on all platforms for interpreter startup. (if we will have the embedded interpreter on more platforms)
On I agreed with the proposal to rename to EXENAME.pth, but rather than supporting all of .pth file's syntax we would abort the process on anything we don't like. Specifically, we'd allow relative paths, absolute paths, blank lines, comments, and "import site". (The parsing code is written in C and runs before initialization, so we can't exec stuff anyway, but if I had my way I'd ban that from .pth files everywhere.) Supporting this on other platforms requires porting the code to Python/getpath.c. I took a quick survey of core devs at the sprints and nobody seemed desperate to have it, but it's something that we can add at any time since it is tied to build/install (rather than anything you'd write in Python code).
