[Python-checkins] r42219 - peps/trunk/pep-0355.txt
python-checkins at python.org
Wed Feb 1 03:32:33 CET 2006
Date: Wed Feb 1 03:32:32 2006
New Revision: 42219
update from B. Lindqvist
--- peps/trunk/pep-0355.txt (original)
+++ peps/trunk/pep-0355.txt Wed Feb 1 03:32:32 2006
@@ -18,6 +18,26 @@
+ 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 . In 2003,
+ Jason Orendorff released version 1.0 of the "path module" which
+ was the first public implementation that used objects to represent
+ paths .
+ The path module quickly became very popular and numerous attempts
+ were made to get the path module included in the Python standard
+ library; , , , .
+ 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.
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): ... 
- 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): ... 
def stat(self): ...
def lstat(self): ...
def statvfs(self): ... 
def pathconf(self, name): ... 
- # Filesystem properties for path.
- atime, mtime, ctime, size
# Methods for manipulating information about the filesystem
def utime(self, times) => None
@@ -318,10 +342,10 @@
- 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()
@@ -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
@@ -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 @@
 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
+  "(idea) subclassable string: path object?", van Rossum, 2001
- * http://mail.python.org/pipermail/python-list/2003-July/174289.html
+  "path module v1.0 released", Orendorff, 2003
- * "(idea) subclassable string: path object?", van Rossum, 2001
+  "Some RFE for review", Birkenfeld, 2005
- * "path module v1.0 released", Orendorff, 2003
+  "path module", Orendorff, 2003
- * http://wiki.python.org/moin/PathClass
+  "PRE-PEP: new Path class", Roth, 2004
- * "PRE-PEP: new Path class",
+  http://wiki.python.org/moin/PathClass
More information about the Python-checkins