PEP on path module for standard library

[Michael Hoffman]

Reinhold Birkenfeld wrote:
> Andrew Dalke wrote:
> 
>>I disagree.  I've tried using a class which wasn't derived from
>>a basestring and kept running into places where it didn't work well.
>>For example, "open" and "mkdir" take strings as input.  There is no
>>automatic coercion.
> 
> Well, as a Path object provides both open() and mkdir() functions, these use
> cases are covered. And that's the point of the Path class: Every common use
> you may have for a path is implemented as a method.

Except when you pass the path to a function written by someone else

> So, it's maybe a good thing that for uncommon uses you have to explicitly
> "cast" the path to a string.

Where uncommon uses include passing the path object to any code you 
don't control? The stdlib can be fixed, this other stuff can't.

>>The solutions to this are:
>>  1) make the path object be derived from str or unicode.  Doing
>>this does not conflict with any OO design practice (eg, Liskov
>>substitution).
>>
>>  2) develop a new "I represent a filename" protocol, probably done
>>via adapt().
>>
>>I've considered the second of these but I think it's a more
>>complicated solution and it won't fit well with existing APIs
>>which do things like
>>
>>
>>  if isinstance(input, basestring):
>>    input = open(input, "rU")
>>  for line in input:
>>    print line
>>
>>I showed several places in the stdlib and in 3rd party packages
>>where this is used.
> 
> That's a valid point. However, if Path is not introduced as a string,
> most new users will not try to use a Path instance where a string is
> needed, just as you wouldn't try to pass a list where a string is wanted.

But many functions were written expecting lists as arguments but also 
work for strings, and do not require an explicit list(mystring) before 
calling the function.
-- 
Michael Hoffman