python -m是拿来干啥用的？

最近看一个project(FCOS)的时候看到一个命令行参数：python -m。就报着好奇心，想要把它搞明白。
其中很多博客都转载这一篇： [python]自问自答：python -m参数？，但是经过测试后，只适用于 python2.x的环境下，对于现在大家都用python3了，里面有点不太正确（但不否定全部）。这里总结一下自己的试验：

实验环境

Ubuntu 18.04.1 LTS + python3.7

例子

我有这么一个文件结构：

├── try_demo
│   ├── package1
│   │   ├── __init__.py
│   │   ├── module1.py
│   ├── package2
│   │   ├── __init__.py
│   │   ├── module2.py

里面的内容是：

• 两个__init__.py都是空的
• module1.py:

import sys
print("module1 is running!")
print("module1 __name__ is:", __name__)
print("now sys.path is:")
print('\n'.join(sys.path))

• module2.py:

import sys
print("module2 is running!")
print("module2 __name__ is:", __name__)
print("now sys.path is:")
print('\n'.join(sys.path))

从下面这句话可以看出，-m这个命令行参数就是像运行一个脚本一样运行模块：
-m mod : run library module as a script (terminates option list)
所以我们试验一下（注意，既然是运行模块，就不要有.py后缀）：

1. 没有-m参数

(base) lsm@lsm:~/文档/try_demo$ python package2/module2.py
module2 is running!
module2 __name__ is: __main__
now sys.path is:
/home/lsm/文档/try_demo/package2
/home/lsm/miniconda3/lib/python37.zip
/home/lsm/miniconda3/lib/python3.7
/home/lsm/miniconda3/lib/python3.7/lib-dynload
/home/lsm/miniconda3/lib/python3.7/site-packages
/home/lsm/文档/FCOS

2. 带-m参数

(base) lsm@lsm:~/文档/try_demo$ python -m package2.module2
module2 is running!
module2 __name__ is: __main__
now sys.path is:
/home/lsm/文档/try_demo
/home/lsm/miniconda3/lib/python37.zip
/home/lsm/miniconda3/lib/python3.7
/home/lsm/miniconda3/lib/python3.7/lib-dynload
/home/lsm/miniconda3/lib/python3.7/site-packages
/home/lsm/文档/FCOS

可以看到，除了调用方式不一样之外，sys.path也不一样：

• 在try_demo目录下调用python package2/module2.py时得到：/home/lsm/文档/try_demo/package2
• 在try_demo目录下调用python -m package2.module2时得到：/home/lsm/文档/try_demo

可以看到，不带-m参数时是把当前模块module2.py目录.../try_demo/package2添加到sys.path中，而带-m参数时是把当前包package2目录.../try_demo添加到sys.path中
然鹅这有什么用呢

改进例子

我在module2.py的第二行加一句话，就能体会出作用：

import sys
from package1 import module1
print("module2 is running!")
print("module2 __name__ is:", __name__)
print("now sys.path is:")
print('\n'.join(sys.path))

再来看一下两种情况下的输出：

1. 没有-m参数

(base) lsm@lsm:~/文档/try_demo$ python package2/module2.py
Traceback (most recent call last):
  File "package2/module2.py", line 2, in <module>
    from package1 import module1
ModuleNotFoundError: No module named 'package1'

2. 带-m参数

(base) lsm@lsm:~/文档/try_demo$ python -m package2.module2
module1 is running!
module1 __name__ is: package1.module1
now sys.path is:
/home/lsm/文档/try_demo
/home/lsm/miniconda3/lib/python37.zip
/home/lsm/miniconda3/lib/python3.7
/home/lsm/miniconda3/lib/python3.7/lib-dynload
/home/lsm/miniconda3/lib/python3.7/site-packages
/home/lsm/文档/FCOS
module2 is running!
module2 __name__ is: __main__
now sys.path is:
/home/lsm/文档/try_demo
/home/lsm/miniconda3/lib/python37.zip
/home/lsm/miniconda3/lib/python3.7
/home/lsm/miniconda3/lib/python3.7/lib-dynload
/home/lsm/miniconda3/lib/python3.7/site-packages
/home/lsm/文档/FCOS

其实这个结果也是我们意料之内的，因为python解释器在导入import的时候会去搜索sys.path下的模块，当不带-m参数时，sys.path只包括到/home/lsm/文档/try_demo/package2，当然不知道还有一个package1，而当带-m参数时，sys.path能包括到/home/lsm/文档/try_demo，此时package1就在/home/lsm/文档/try_demo下呀

至此可以总结出-m能给我们的好处是：已知一个模块的名字，但不知道它的文件路径，那么使用“-m”就意味着交给解释器自行查找，在所有模块命名空间中查找，定位到脚本的路径，则当成脚本执行。

拓展(expansion)

“-m”之后也可以直接接一个包的名字，那么解释器经过前面提到的查找过程，先定位到该包，但是会去执行它的__main__子模块，也就是说，在包目录下必须要实现一个__main__.py文件。
换句话说，假设有个包的名称是“packname”，那么，“python -m packname”，其实就等效于python -m packname.__main__。

赶紧试验一下是不是：

1. 在package1下没有__main__.py文件

(base) lsm@lsm:~/文档/try_demo$ python -m package1
/home/lsm/miniconda3/bin/python: No module named package1.__main__; 'package1' is a package and cannot be directly executed

2. 在package1下有__main__.py文件，里面只写print("this is package1.__main__")这一句话

(base) lsm@lsm:~/文档/try_demo$ python -m package1
this is package1.__main__

TODO

眼尖的小伙伴都已经看出来了在改进例子中的运行带-m参数的命令时，出现了：
module1 __name__ is: package1.module1，不再是__main__，这个下次再查查为什么？我想跟大家都在用的用法：__name__ == '__main__'有关联吧？

参考(references)

Python 中 -m 的典型用法、原理解析与发展演变
官方文档对于-m介绍
官方文档对于Executing modules as scripts的介绍