PEP on path module for standard library

Michael Hoffman at mh391.invalid
Fri Jul 22 22:03:51 CEST 2005

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
>>  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

More information about the Python-list mailing list