"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Most prominent change is that it doesn't inherit from str/unicode > anymore. > I found this distinction important, because as a str subclass the Path > object > has many methods that don't make sense for it.
While I am - on adding more to learn, I am + on collecting scattered filesystem functions into methods of coherent classes for eventually replacement of the former. And I understand that this will mean a period of duplication. But it is important to get the replacement right. My only knowledge of the path module is what has been posted. However, it seems to me that a path is conceptually a sequence of strings, rather than the single joined-string representation thereof. If so, then of course it is not and should not be a subclass of single strings. But that Path was so defined makes me wonder, in my ignorance, whether the current implementation is the best we can do for the future. One advantage, for instance, of a split-up list implementation is that a set of paths with a common prefix could be represented by replacing the last string with a set of strings. A more OO-friendly OS than the dominant ones today would accept a path as a list (sequence) instead of requiring that the list be joined (by an artifactual character) just to be split back into a list again. My thoughts anyway. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
