PEP on path module for standard library

[Terry Reedy]

"Reinhold Birkenfeld" <reinhold-birkenfeld-nospam at wolke7.net> wrote in 
message news:3kacleFslj6sU1 at individual.net...
> 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