<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/archive%40mail-archive.com
