There are fundamental differences between .py files and .exe files (as I know you know). As a simple example, subprocess.run(['pip', 'install', 'foo']) will fail to find your pip.py. As another example, VS Code doesn’t recognise .py files as OS commands (at least it didn’t for things like pylint when I last tried…) This is probably fixable at the tool level, but that was sort of my point - it needs tool support, and it doesn’t fix -m directly.
IMO, -m is an incredibly useful and effective feature. The problem is not so much with -m as it is with the whole question of “what is a Python application”. In practical terms, there are various ways of deploying Python code:
- Standalone scripts
- Libraries that expose command line interfaces
- Full applications
-m is perfect for (2), as are console scripts. But they get used for (3) as well, because there’s no particularly good solution for (3). And of course __pypackages__ is ideal for (1) (supplementing things like zipapps).
My point about python -m pip or python -m black wasn’t so much that -m is bad, as that pip and black should probably be distributed as type (3) applications, but the lack of a good lightweight solution for that makes it impractical. This brings us back to this thread, of course…