[Python-checkins] peps: Tweak the reasoning for pathlib not sublcassing str.

[brett.cannon]

https://hg.python.org/peps/rev/b79086c6626f
changeset:   6293:b79086c6626f
user:        Brett Cannon <brett at python.org>
date:        Sat Apr 23 09:04:27 2016 -0700
summary:
  Tweak the reasoning for pathlib not sublcassing str.

files:
  pep-0428.txt |  15 +++++++--------
  1 files changed, 7 insertions(+), 8 deletions(-)


diff --git a/pep-0428.txt b/pep-0428.txt
--- a/pep-0428.txt
+++ b/pep-0428.txt
@@ -156,14 +156,13 @@
 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
 

-- 
Repository URL: https://hg.python.org/peps