Grr, in doing the Py3k forward port I found the hack based on the "-c" entry that I remembered (I had mentioned it *right there* in a comment in main.c, so I don't know how I missed it when first updating 2.7 - I suspect I got lost in the ifdef maze inside SetArgV and managed to convince myself it wasn't a problem).

Anyway, it turns out PySys_SetArgV() uses the "sys.argv[0] == '-c'" check to skip over checking the file system for a file by that name. By reusing that same value, the -m code was able to also skip that check without needing to add any additional checks in the sysmodule code.

With the change I made to the 2.x branch, 2.7 now reacts differently if someone creates a "-m" file in the launch directory:

:~/devel/python$ python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
:~/devel/python$ ./python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
>>> 
:~/devel/python$ cat > -m
dd
:~/devel/python$ cat < -m
dd
:~/devel/python$ python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
:~/devel/python$ ./python -i -m runpy
No module specified for execution
>>> sys.path[0]
'/home/ncoghlan/devel/python'
>>> 

System python is 2.6, local Python is SVN head. Note that the version from SVN changes behaviour after I create the oddly named file, while the system Python is unaffected.

My inclination is to fix this properly for 3.2 (including some extra command line tests to ensure that files named "-c" and "-m" don't confuse the sys.path configuration), but revert the change completely for 2.7.

Added Benjamin for an opinion, since 2.7 is in RC mode already.