pythonスクリプトの起動モード(python-mはモジュールで起動します)

今日はpythonのプロジェクトを見ていますが、GitHubで提供されているpythonスクリプトの実行フォーマットはpython-m pip install somepackageです.そして、pythonモード起動の旅を開始しました.
その中の多くはこのブログを参考にしました.http://www.cnblogs.com/xueweihan/p/5118222.html

python起動モジュールは何ですか?
pythonでライブラリ内のモジュール(python起動モジュール)を起動します.
python-m http.server    (python 3で簡単なhttpサーバーを起動します)

pythonに関するモジュール方式起動

pythonの起動方式(pyファイルを読み込む方式)は2つあります.
 

python xx.py  -----直接運転の方式で起動します.このときシナリオ_name_u

python-m xx.py  ------モジュールとして起動する(この時点でシナリオの_name_u属性値は依然として「_main_」ではなく「xxx」)

附:__name_==「_まいまいまいまいまい」はこのスクリプトがプログラムのメインエントランスであることを示しています.そうでないとモジュール呼び出しで実行されます.
違い1:
二つの起動方式の違いについては、主にロードされたシステムパスが異なる(sys.pathリスト):(列を通して検証された)
ホーム/スパーク/cluster-master/examplesでtest.pyスクリプトを作成します.内容:

  import sys
  print(sys.path)

1、直接運行:python test.py結果:

['/home/spark/cluster-master/examples', '/home/spark/cluster-master', '/data/lthpc/soft/caffe/python', '/opt/anaconda3/lib/python36.zip', '/opt/anaconda3/lib/python3.6', '/opt/anaconda3/lib/python3.6/lib-dynload', '/opt/anaconda3/lib/python3.6/site-packages', '/opt/anaconda3/lib/python3.6/site-packages/Sphinx-1.5.6-py3.6.egg', '/opt/anaconda3/lib/python3.6/site-packages/setuptools-27.2.0-py3.6.egg', '/opt/anaconda3/lib/python3.6/site-packages/torchvision-0.1.9-py3.6.egg']

2、モジュール方式で運行する:python-m test結果:

['', '/home/spark/cluster-master/examples', '/data/lthpc/soft/caffe/python', '/opt/anaconda3/lib/python36.zip', '/opt/anaconda3/lib/python3.6', '/opt/anaconda3/lib/python3.6/lib-dynload', '/opt/anaconda3/lib/python3.6/site-packages', '/opt/anaconda3/lib/python3.6/site-packages/Sphinx-1.5.6-py3.6.egg', '/opt/anaconda3/lib/python3.6/site-packages/setuptools-27.2.0-py3.6.egg', '/opt/anaconda3/lib/python3.6/site-packages/torchvision-0.1.9-py3.6.egg']

異なる点に注意してください.直接運転後のパスは「スクリプトのパス」であり、モジュール方式で実行した後に「」が追加されました.この「」記号はpython実行環境の現在のパス(pythonの実行経路)を表しています.この「」の現在のパスはimportパッケージを引き出した時の多くの問題です.以下の例で説明します.
下の例はサーバーで検証できませんでした.とりあえず他の人の例を貼ります.

#       
package/
    __init__.py
    mod1.py
package2/
    __init__.py
    run.py  

# run.py     
import sys
from package import mod1
print(sys.path)

 
二つの起動:
 

#     （  ）
➜  test_import_project git:(master) ✗ python package2/run.py
Traceback (most recent call last):
  File "package2/run.py", line 2, in 
    from package import mod1
ImportError: No module named package

#        （  ）
➜  test_import_project git:(master) ✗ python -m package2.run
['',
'/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
...]

起動成功かどうかの鍵は、run.pyスクリプトのimportコンテンツがsys.pathに成功的に参加できるかどうかです.
明らかにfrom package import mod 1は、sys.pathに'現在のパスがある場合は対応するパケットを見つけることができますが、他の方法は、pythonのモジュール検索パス機構にあるので、パケットが見つからないです.
違い2:

-mパラメータを加えると、まずモジュールまたはパッケージを導入してから実行します.

もし次のようなパッケージがあるとします.

package
├── __init__.py
└── __main__.py

__init__.pyの内容

import sys

print("__init__")
print(sys.path)

__main__.pyの内容

import sys

print("__main__")
print(sys.path)

python -m packageを使って実行し、結果を出力します.

__init__
['', ...]

__main__
['', ...]

python packageを使って実行し、結果を出力します.

__main__
['package', ...]

ここでは名前のモジュールに関して、__main__.pyファイルはパッケージまたはディレクトリのエントリプログラムです.python packageを使ってもpython -m packageで動作しても、__main__.pyファイルは常に実行されます. 
 
モジュールが導入されると、PVMはバックグラウンドで一連のパスからモジュールを検索します.その検索プロセスは以下の通りです.
1、現在のディレクトリの下でモジュールを検索します.
2、環境変数PYTHOPATHで指定されたパスリストから順次検索します.
3、pythonのインストール経路で検索する
      実際、PVMは変数sys.pathに含まれるパスを通じて検索します.この変数に含まれるパスリストは上記のような経路情報です.