2009-08-10 81 views
7

想知道有多少人在Python中使用路徑模塊,比如Jason Orendorff的路徑模塊,而不是使用os.path來加入和分割路徑?你用過:Python人使用哪個路徑模塊或類來代替os.path?

我知道Jason的路徑模塊被製作成PEP 355並被BDFL拒絕。這看起來好像主要是因爲它試圖在一個班級中做所有事情。

我們的用例主要是爲了簡化連接和拆分路徑的組件,所以如果這樣的路徑類只實現split/join類型的操作,我們會非常高興。誰不想這樣做:

path(build_dir, path(source_file).name) 

或本:

build_dir/path(source_file).name 

,而不是這樣的:

os.path.join(build_dir, os.path.basename(source_file)) 
+0

看起來像[Python 3只有pathlib(https://www.python.org/dev/ peps/pep-0428 /),還有[Python 2的backport](https://pypi.python.org/pypi/pathlib2/)。 – 2017-04-25 17:44:23

回答

11

我可以拿起一個Python程序和解釋現行標準方法毫不猶豫 - 這是明確的,沒有歧義:

os.path.join(build_dir, os.path.basename(source_file)) 

Python的動態類型使得第一種方法比較困難閱讀時理解:

build_dir/path(source_file).name 

加上它是不常見的分割字符串,它帶來了更多的混亂。我怎麼知道這兩個不是整數?還是漂浮?如果兩者都以非字符串類型結尾,則不會在運行時獲得TypeError。

最後,

path(build_dir, path(source_file).name) 

如何,任何比os.path中方法更好?

雖然他們可能會「簡化」編碼(即使編寫起來更容易),但如果其他不熟悉替代模塊的人需要維護代碼,那麼就會陷入衝突。

所以我想我的答案是:我不使用替代路徑模塊。 os.path已經擁有了我所需要的一切,而且它的接口並不是一件壞事。

+2

聽到了!標準的os.path模塊沒有什麼可怕的錯誤來保證爲你的項目增加更多的依賴。如果你有一個特別多毛的路徑構造問題,比如從一個對象層次結構中構建一條路徑,那麼爲什麼不把它包裝在一個函數中呢?下一個程序員會感謝你封裝它,並且不讓他學習和調試整個其他模塊。 – Theran 2009-08-10 00:16:16

+0

謝謝你的回答,馬修。好的評論,Theran:你把事情分解成函數是正確的 - 這已經簡化了我的腳本。事實上,我認爲你們兩個已經說服了我們。另外,如果我們只是想要更簡潔一點,我想總會有「從os導入路徑」。 – 2009-08-10 02:41:34

+0

沒有歧義,正確,但寫起來很痛苦,很難讀。我寧願處理一個不變的Path對象,如Java的['java.nio.file.Path'](https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path。 HTML)比一個字符串。例如:'with build_dir.child('config.yaml')。open()as f' vs'with open(os.path.join(build_dir,'config.yaml'))as f' - 邏輯流程是更一致地從左到右,並且嵌套的括號更少,所以更易於閱讀和理解。 – 2017-04-25 17:32:13

-1

將字符串分割成連接路徑可能看起來像是一個「巧妙的技巧」,但正是Python程序員喜歡避免的那種事情(以及其他大多數語言中的程序員)。os.path模塊被廣泛使用,所有人都很容易理解。另一方面,使用重載操作符做時髦的事情是令人困惑的,它會損害代碼的可讀性,這是Python的強項之一。另一方面,C++程序員喜歡那種事情。也許這就是C++代碼難以閱讀的原因之一。

2

一個簡單而有用的技巧是這樣的:

進口OS

路徑= os.path.join

然後,而不是這樣的:

OS .path.join(build_dir,os.path.basename(source_file))

你可以這樣做:

路徑(build_dir,路徑(SOURCE_FILE))

+1

我一直這樣做,但我使用'pj'而不是'路徑'。 :-) – 2012-03-02 06:20:36

相關問題