Björn Lindqvist restarted the discussion about getting Path into the stdlib in January. The PEP and reference implementation is available here: PEP 355, PathModule, PathModuleTests

There are alternative proposals as well: AlternativePathClass, AlternativePathDiscussion, AlternativePathModuleTests

Path class Pre-Pre-PEP


The Python Standard Library currently has many modules that allow the developer to interact with the filesystem. Currently this set of modules is:

This PEP proposes that a new class or module be added to the Python Standard Library that will make all filesystem operations available from one place in a consistent way.

Reference Implementation

Reinhold has modified Jason Orendorff's original to fit discussions in python-dev and comp.lang.python and has placed it in Python under nondist/sandbox/path:

Other implementations to look at include the original, and some things that others have mentioned on c.l.p. and python-dev.

Jason Orendorff's original can be found here:


The motivation for a single standard class or module to handle filesystem operations is threefold:

Design Principles

1. A Path should be a drop-in replacement for a str or unicode as much as possible.

2. Properties are the interface for actual attributes of a Path. For example, a Path's basename will be the same regardless of data on the local filesystem. Accessing a Path property will never result in an IOError.

3. Methods are the interface for attributes of whatever the Path represents, for example, the last-modified-time or contents of a file. Calling a Path method may result in an IOError if the method accesses the actual filesystem and finds a problem (e.g. the Path refers to a nonexistent file).

4. [Done in CVS] Should be subclassable so third parties can offer richer subclasses. Use self.__class__() instead of Path() in method bodies. Alternate constructors like Path.cwd() should be a class methods rather than static methods. (MikeOrr)

Backwards Compatibility

If this PEP is accepted, then several of the existing standard modules will become redundant, which violates the TOOWTDI principle. The following modules will become redundant:

It is proposed that Python 2.5 will mark redundant modules as deprecated and issue a warning when they are imported. The functionality that these modules offer should be moved into the path module.

Python 2.6 will remove the redundant modules from the standard library.

Open Issues


PathClass (last edited 2009-09-13 06:07:15 by 216)

Unable to edit the page? See the FrontPage for instructions.