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 -- http://mail.python.org/mailman/listinfo/python-list
