[Python-checkins] r42219 - peps/trunk/pep-0355.txt

david.goodger python-checkins at python.org
Wed Feb 1 03:32:33 CET 2006


Author: david.goodger
Date: Wed Feb  1 03:32:32 2006
New Revision: 42219

Modified:
   peps/trunk/pep-0355.txt
Log:
update from B. Lindqvist

Modified: peps/trunk/pep-0355.txt
==============================================================================
--- peps/trunk/pep-0355.txt	(original)
+++ peps/trunk/pep-0355.txt	Wed Feb  1 03:32:32 2006
@@ -18,6 +18,26 @@
     and recommended.
 
 
+Background
+
+    The ideas expressed in this PEP are not recent, but have been
+    debated in the Python community for many years.  Many have felt
+    that the API for manipulating file paths as offered in the os.path
+    module is inadequate.  The first proposal for a Path object was
+    raised by Just van Rossum on python-dev in 2001 [2].  In 2003,
+    Jason Orendorff released version 1.0 of the "path module" which
+    was the first public implementation that used objects to represent
+    paths [3].
+
+    The path module quickly became very popular and numerous attempts
+    were made to get the path module included in the Python standard
+    library; [4], [5], [6], [7].
+
+    This PEP summarizes the the ideas and suggestions people have
+    expressed about the path module and proposes that a modified
+    version should be included in the standard library.
+
+
 Motivation
 
     Dealing with filesystem paths is a common task in any programming
@@ -180,19 +200,23 @@
         def islink(self): ...
         def ismount(self): ...
         def samefile(self, other): ...  [1]
-        def getatime(self): ...
-        def getmtime(self): ...
-        def getctime(self): ...
-        def getsize(self): ...
+        def atime(self): ...
+            """Last access time of the file."""
+        def mtime(self): ...
+            """Last-modified time of the file."""
+        def ctime(self): ...
+            """
+            Return the system's ctime which, on some systems (like
+            Unix) is the time of the last change, and, on others (like
+            Windows), is the creation time for path.
+            """
+        def size(self): ...
         def access(self, mode): ...  [1]
         def stat(self): ...
         def lstat(self): ...
         def statvfs(self): ...  [1]
         def pathconf(self, name): ...  [1]
 
-        # Filesystem properties for path.
-        atime, mtime, ctime, size
-
         # Methods for manipulating information about the filesystem
         # path.
         def utime(self, times) => None
@@ -318,10 +342,10 @@
         islink()                os.path.islink()
         ismount()               os.path.ismount()
         samefile()              os.path.samefile()
-        getatime()/atime        os.path.getatime()
-        getctime()/ctime        os.path.getctime()
-        getmtime()/mtime        os.path.getmtime()
-        getsize()/size          os.path.getsize()
+        atime()                 os.path.getatime()
+        ctime()                 os.path.getctime()
+        mtime()                 os.path.getmtime()
+        size()                  os.path.getsize()
         cwd()                   os.getcwd()
         access()                os.access()
         stat()                  os.stat()
@@ -371,6 +395,18 @@
       the Path object.  These changes obsoleted the problematic
       joinpath() method which was removed.
 
+    * The methods and the properties getatime()/atime,
+      getctime()/ctime, getmtime()/mtime and getsize()/size duplicated
+      each other.  These methods and properties have been merged to
+      atime(), ctime(), mtime() and size().  The reason they are not
+      properties instead, is because there is a possibility that they
+      may change unexpectedly.  The following example is not
+      guaranteed to always pass the assertion:
+
+        p = Path("foobar")
+        s = p.size()
+        assert p.size() == s
+
 
 Open Issues
 
@@ -392,12 +428,31 @@
     * The name obviously has to be either "path" or "Path," but where
       should it live?  In its own module or in os?
 
-    * Path implements two ways to retrieve some filesystem
-      information.  Both the properties atime, mtime, ctime and size
-      and the getters getatime(), getmtime(), getctime() and
-      getsize().  This is clearly not optimal, the information should
-      *either* be retrieved using properties or getters.  Both methods
-      have advantages and disadvantages.
+    * Due to Path subclassing either str or unicode, the following
+      non-magic, public methods are availible on Path objects:
+
+        capitalize(), center(), count(), decode(), encode(),
+        endswith(), expandtabs(), find(), index(), isalnum(),
+        isalpha(), isdigit(), islower(), isspace(), istitle(),
+        isupper(), join(), ljust(), lower(), lstrip(), replace(),
+        rfind(), rindex(), rjust(), rsplit(), rstrip(), split(),
+        splitlines(), startswith(), strip(), swapcase(), title(),
+        translate(), upper(), zfill()
+
+      On python-dev it has been argued whether this inheritance is
+      sane or not.  Most persons debating said that most string
+      methods doesn't make sense in the context of filesystem paths --
+      they are just dead weight.  The other position, also argued on
+      python-dev, is that inheriting from string is very convenient
+      because it allows code to "just work" with Path objects without
+      having to be adapted for them.
+
+      One of the problems is that at the Python level, there is no way
+      to make an object "string-like enough," so that it can be passed
+      to the builtin function open() (and other builtins expecting a
+      string or buffer), unless the object inherits from either str or
+      unicode.  Therefore, to not inherit from string requires changes
+      in CPython's core.
 
     The functions and modules that this new module is trying to
     replace (os.path, shutil, fnmatch, glob and parts of os) are
@@ -472,24 +527,22 @@
 
     [1] Method is not guaranteed to be availible on all platforms.
 
-    Related articles & threads:
-
-    * http://mail.python.org/pipermail/python-dev/2005-June/054439.html
-
-    * http://mail.python.org/pipermail/python-list/2005-July/291071.html
+    [2] "(idea) subclassable string: path object?", van Rossum, 2001
+        http://mail.python.org/pipermail/python-dev/2001-August/016663.html
 
-    * http://mail.python.org/pipermail/python-list/2003-July/174289.html
+    [3] "path module v1.0 released", Orendorff, 2003
+        http://mail.python.org/pipermail/python-announce-list/2003-January/001984.html
 
-    * "(idea) subclassable string: path object?", van Rossum, 2001
-      http://mail.python.org/pipermail/python-dev/2001-August/016663.html
+    [4] "Some RFE for review", Birkenfeld, 2005
+        http://mail.python.org/pipermail/python-dev/2005-June/054438.html
 
-    * "path module v1.0 released", Orendorff, 2003
-      http://mail.python.org/pipermail/python-announce-list/2003-January/001984.html
+    [5] "path module", Orendorff, 2003
+        http://mail.python.org/pipermail/python-list/2003-July/174289.html
 
-    * http://wiki.python.org/moin/PathClass
+    [6] "PRE-PEP: new Path class", Roth, 2004
+        http://mail.python.org/pipermail/python-list/2004-January/201672.html
 
-    * "PRE-PEP: new Path class",
-      http://mail.python.org/pipermail/python-list/2004-January/201672.html
+    [7] http://wiki.python.org/moin/PathClass
 
 
 Copyright


More information about the Python-checkins mailing list