[Python-Dev] PEP 355 status

Nick Coghlan ncoghlan at gmail.com
Sun Oct 1 05:56:53 CEST 2006

Giovanni Bajo wrote:
> Guido van Rossum wrote:
>> OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor)
>> can update the PEP.
>> I'm looking forward to a new PEP.
> It would be terrific if you gave us some clue about what is wrong in PEP355, so
> that the next guy does not waste his time. For instance, I find PEP355
> incredibly good for my own path manipulation (much cleaner and concise than the
> awful os.path+os+shutil+stat mix), and I have trouble understanding what is
> *so* wrong with it.
> You said "it's an amalgam of unrelated functionality", but you didn't say what
> exactly is "unrelated" for you.

Things the PEP 355 path object lumps together:
   - string manipulation operations
   - abstract path manipulation operations (work for non-existent filesystems)
   - read-only traversal of a concrete filesystem (dir, stat, glob, etc)
   - addition & removal of files/directories/links within a concrete filesystem

Dumping all of these into a single class is certainly practical from a utility 
point of view, but it's about as far away from beautiful as you can get, which 
creates problems from a learnability point of view, and from a 
capability-based security point of view. PEP 355 itself splits the methods up 
into 11 distinct categories when listing the interface.

At the very least, I would want to split the interface into separate abstract 
and concrete interfaces. The abstract object wouldn't care whether or not the 
path actually existed on the current filesystem (and hence could be relied on 
to never raise IOError), whereas the concrete object would include the many 
operations that might need to touch the real IO device. (the PEP has already 
made a step in the right direction here by removing the methods that accessed 
a file's contents, leaving that job to the file object where it belongs).

There's a case to be made for the abstract object inheriting from str or 
unicode for compatiblity with existing code, but an alternative would be to 
enhance the standard library to better support the use of non-basestring 
objects to describe filesystem paths. A PEP should at least look into what 
would have to change at the Python API level and the C API level to go that 
route rather than the inheritance route.

For the concrete interface, the behaviour is very dependent on whether the 
path refers to a file, directory or symlink on the current filesystem. For an 
OO filesystem interface, does it really make sense to leave them all lumped 
into the one class with a bunch of isdir() and islink() style methods? Or does 
it make more sense to have a method on the abstract object that will return 
the appropriate kind of filesystem info object? If the latter, then how would 
you deal with the issue of state coherency (i.e. it was a file when you last 
touched it on the filesystem, but someone else has since changed it to a 
link)? (that last question actually lends strong support to the idea of a 
*single* concrete interface that dynamically responds to changes in the 
underlying filesystem).

Another key difference between the two is that the abstract objects would be 
hashable and serialisable, as their state is immutable and independent of the 
filesystem. For the concrete objects, the only immutable part of their state 
is the path name - the rest would reflect the state of the filesystem at the 
current point in time.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list