iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Tweak the reasoning for pathlib not sublcassing str.

This commit is contained in:
Brett Cannon 2016-04-23 09:04:27 -07:00
parent 6d08f32de7
commit 084c8e2b83
1 changed files with 7 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
pep-0428.txt
View File

@ -156,14 +156,13 @@ contrasts with some other Path class proposals which were derived from
if you want a path to act as a sequence, you have to lookup a dedicated
attribute (the ``parts`` attribute).
The key reasoning behind not inheriting from ``str`` is to prevent confusing
any object that has a string representation -- which is all Python objects --
with a path object. This avoids situations when people must interface with an
API that mandates a string representation for a file system path, tempting you
to use ``str(path)`` to extract the string representation of the path. This
would be a problem if ``path = None; open(str(path), 'w')``. A `blog post`_ by
a Python core developer goes into more detail on the reasons behind this
specific design decision.
The key reasoning behind not inheriting from ``str`` is to prevent accidentally
performing operations with a string representing a path and a string that
doesn't, e.g. ``path + an_accident``. Since operations with a string will not
necessarily lead to a valid or expected file system path, "explicit is better
than implicit" by avoiding accidental operations with strings by not
subclassing it. A `blog post`_ by a Python core developer goes into more detail
on the reasons behind this specific design decision.
.. _blog post: http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str