[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