PEP on path module for standard library

[Duncan Booth]

George Sakkis wrote:

>> Read literally, this says (at least to me) "I don't want to fix it
>> because I don't think it's broke."
> 
> Or rather "I prefer a single existing mediocre solution than two
> solutions (even if the second was better)".
> 
Except that he is open to persuasion, so the PEP has to demonstrate that 
the duplication is worth the benefit.

Personally I think the concept of a specific path type is a good one, but 
subclassing string just cries out to me as the wrong thing to do. In other 
words, to me a path represents something in a filesystem, the fact that it 
has one, or indeed several string representations does not mean that the 
path itself is simply a more specific type of string.

You should need an explicit call to convert a path to a string and that 
forces you when passing the path to something that requires a string to 
think whether you wanted the string relative, absolute, UNC, uri etc.

It may even be that we need a hierarchy of path classes: URLs need similar 
but not identical manipulations to file paths, so if we want to address the 
failings of os.path perhaps we should also look at the failings of urlparse 
at the same time.