From 734743d99b78e42739b1c1bfbdec838875bc4694 Mon Sep 17 00:00:00 2001 From: Antoine Pitrou Date: Wed, 20 Nov 2013 00:46:39 +0100 Subject: [PATCH] Assorted comments by Jim Jewett --- pep-0428.txt | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/pep-0428.txt b/pep-0428.txt index 7420079be..2bb88cbca 100644 --- a/pep-0428.txt +++ b/pep-0428.txt @@ -155,8 +155,8 @@ 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). -By avoiding to pass as builtin types, the path classes minimize the potential -for confusion if they are combined by accident with genuine builtin types. +Not behaving like one of the basic builtin types also minimizes the potential +for confusion if a path is combined by accident with genuine builtin types. Immutability @@ -201,6 +201,9 @@ Paths of different flavours always compare unequal, and cannot be ordered:: File "", line 1, in TypeError: unorderable types: PurePosixPath() < PureWindowsPath() +Paths compare unequal to, and are not orderable with instances of builtin +types (such as ``str``) and any other types. + Useful notations ---------------- @@ -315,7 +318,8 @@ which is a special case in the POSIX specification on `pathname resolution`_ PurePosixPath('//some/path') Calling the constructor without any argument creates a path object pointing -to the logical "current directory":: +to the logical "current directory" (without looking up its absolute path, +which is the job of the ``cwd()`` classmethod on concrete paths):: >>> PurePosixPath() PurePosixPath('.')