起步

既然所有路徑都可以表示為字符串，為什么 pathlib.Path 不繼承 str ? 這個想法的提出在 https://mail.python.org/pipermail//python-ideas/2016-April/039475.html 可以看到，其中，還提出了將 p'/some/path/to/a/file' 返回 path.Path 實例的想法。

路徑都是字符串嗎？

從面向對象的繼承的思想來看，如果 Path 繼承自 str ，那么所有的路徑都應該是字符串。但所有的路徑都是字符串嗎？答案是不。在 POSIX 的接口中，允許二進制字符串作為路徑。也就是說路徑還有二進制路徑的形式存在。所以并不是所有路徑都是字符串，盡管所有路徑確實都能用字符串表示。

文件系統(tǒng)路徑協(xié)議
基于上述原因，Python 提出了文件系統(tǒng)路徑協(xié)議的提案 PEP-519 ,該協(xié)議提供str 或 bytes 來表示的文件系統(tǒng)路徑。這個協(xié)議也就誕生了處理路徑的 pathlib 模塊 PEP-428，該模塊遵守了路徑協(xié)議并將路徑視為對象。

協(xié)議的實現(xiàn)一般也是通過鴨子協(xié)議來滿足，這點出發(fā) Path 也沒必要繼承 str 。

不是字符串的Path使用上有什么影響

在 Python3.5 及以下將不能用 Path 作為open的參數(shù)：

import pathlib
p = pathlib.Path('a.txt')
content = open(p, 'r').read() # 換成 open(str(p), 'r') 可以運行

將會報錯：

TypeError: invalid file: PosixPath('a.txt')

但這點在 Python3.6 得到的改善: https://docs.python.org/3/whatsnew/3.6.html#pep-519-adding-a-file-system-path-protocol

內(nèi)置 open() 函數(shù)已更新為接受 os.PathLike 對象，os 和 os.path 模塊中的所有相關函數(shù)以及大多數(shù)其他函數(shù)和類標準庫都使用了文件路徑系統(tǒng)協(xié)議。

>>> import pathlib
>>> with open(pathlib.Path("README")) as f:
...   contents = f.read()
...
>>> import os.path
>>> os.path.splitext(pathlib.Path("some_file.txt"))
('some_file', '.txt')
>>> os.path.join("/a/b", pathlib.Path("c"))
'/a/b/c'
>>> import os
>>> os.fspath(pathlib.Path("some_file.txt"))
'some_file.txt'

對于低版本的可以使用兼容性更好的：

with p.open('r') as f:
  content = f.read()

如果路徑繼承str會怎樣

或者說如果我自己創(chuàng)建個路徑類繼承自 str ，這當然可以，也沒人組織你，但我想從設計上闡述下這個做法的弊端。

一方面，這個做法會讓路徑隱式地視為字符串。不滿足Python之禪的 顯式勝于隱式 的理念。

另一方面也是比較重要的一點，這個做法淡化了 str 和 bytes 的界限，想想Python 2中二進制文本數(shù)據(jù)和文本數(shù)據(jù)的隱式兼容性導致了一個令人頭疼的問題，將在這里又重新埋下隱患。這是倒退式的做法。

總結

對于路徑類為什么不繼承字符串，本文從路徑的形式，路徑協(xié)議，以及API設計解釋了。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。

擴展閱讀

• Python-ideas: Making pathlib paths inherit from str
• PEP 519 -- Adding a file system path protocol
• PEP 428 -- The pathlib module -- object-oriented filesystem paths

最新評論