[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] The path module PEP
From:       VanL <news-nospam () northportal ! net>
Date:       2006-01-26 19:23:30
Message-ID: drb7j4$2cn$1 () sea ! gmane ! org
[Download RAW message or body]

<Delurking>

The path module has a great idea, but it does too much -- it conflates 
too many ideas into a single module.

It has methods for dealing with files (open, bytes, read, etc) as well 
as methods for dealing with a filesystem tree as a whole (relpath, 
abspath, etc).  Both of these ideas are tangentially related to paths, 
but really aren't in the same conceptual box.

Not too long ago, I had to build something loosely based upon the path 
module.  Instead of using it as-is, I broke it up into three modules:

Tree (filesystem interfaces)
Path (*just* path interfaces)
File (a generic filelike object)

Doing it this way had two benefits:

First, it put different concepts into different modules.  I note that 
some other virtual filesystem modules also maintedned a similar 
separation - probably for similar reasons.

Second, I was able to define an interface which could be used across 
remote systems -- e.g. I was able to have an FTPTree (built on the 
standard library ftplib) and SSHTree (built upon paramiko) as well as 
FileTree (a standard filesystem).  This isn't full-fledged interfaces - 
I just implemented common functionality in a class and then delegated to 
a ._ops class which passed through the necessary operations.  However, I 
was able to use the various trees and file-like objects interchangeably.


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]