なぜlistdir（）関数がosモジュールの一部であり、os.pathの一部ではないのですか？

Question

os.pathモジュールは、すべてのパス関連機能のデフォルトモジュールのようです。しかし、listdir()関数は、osモジュールの一部であり、入力としてパスを受け入れるとしても、os.pathモジュールではありません。なぜこの意思決定がなされたのでしょうか？

Answer 1

私は個人的にはosとos.pathの間に少し矛盾があります。ドキュメントによると、os.pathは、特定のプラットフォーム（つまり、OS X、Linux、およびBSDの場合はposixpath、Windowsまたは古代のMacの場合は別のものが得られる）上のパスで動作するモジュールの別名にする必要があります）。

 
>>> import os 
>>> help(os) 
Help on module os: 

NAME 
    os - OS routines for Mac, NT, or Posix depending on what system we're on. 
... 
>>> help(os.path) 
Help on module posixpath: 

NAME 
    posixpath - Common operations on Posix pathnames. 

listdir機能ではなく、それはパスで識別されるディレクトリ上で動作し、パス自体には動作しません。 os.pathの関数のほとんどは、実際のパスで動作し、ではなく、ファイルシステム上のです。

これは、os.pathの多くの関数が文字列操作関数であり、osのほとんどの関数がIO関数/ syscallsであることを意味します。

例：

• os.path.join、os.path.dirname、os.path.splitext、単なる文字列操作関数です。

• os.listdir、os.getcwd、os.remove、os.statは、すべてのシステムコールであり、実際にファイルシステムをタッチします。

反例：

• os.pathexists、getmtime、islink、基本的os.statのラッパーである他人を有し、ファイルシステムをタッチ。私はそれらを分類していないと考えますが、他の人はそれに同意しないかもしれません。

日の

楽しいファクト：あなたは、ライブラリのドキュメントのトップレベルのモジュールを見つけることができませんが、あなたは実際に実際にそのプラットフォーム上で実行することなく、任意のプラットフォーム用os.pathのバージョンをインポートすることができます。これは、しかし、あなたはまた、インポートして、異なる形式のいずれかで常にパスを操作したい場合は、個々のモジュールを使用することができます

、os.pathのドキュメントに記載されています。彼らは皆、同じインタフェースがあります

UNIX形式のパスのための

• posixpath
、Windowsのパスの
• ntpath
古いスタイルのための
• macpath MacOSのパスをOS/2 EMXパスの
• os2emxpath

osと同じことをすることはできません。 nse。