It occurs to me that there may be some additional unshared context here: the way `python -m pip` searches for the module to execute is much closer to the way Windows searches for a command like `pip` (i.e. current directory first) than it is to the way *nix systems search for it (i.e. if the current directory isn't on PATH it must be specified explicitly as "./pip"). If you spend a lot of time on Windows systems, or working with Windows users, it becomes a habit to assume that folks aren't going to expect it to be safe to run arbitrary commands from arbitrary directories.

This behaviour means that if you want to intercept "python -m pip", the current easiest filename to use to intercept it is just "pip.py", similar to the way you can use "pip.exe"  or "python.exe" to intercept those commands on Windows.

I do think switching from a Windows-style default search behaviour to a *nix style default search behaviour is potentially reasonable, but the related backwards compatibility considerations would likely push it into being a PEP level change.

I'll also note that Nathaniel's right that I was wrong about `sitecustomize` always being easy to intercept from the current directory, though, as sys.path[0] gets set *after* "import site" has already executed.

I was just confusing myself, as my default approach to double-checking the behaviour of the "-m" switch is to run "python -m site", but that's misleading in this case since doing that *also* re-runs the site and user customisation modules (and will pick them up from the current working directory) - it's closely akin to testing `python3 -c "import runpy; runpy.run_module('site', run_name='__main__')"`