"Duncan Booth" <[EMAIL PROTECTED]> wrote: > 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.
First off, I find this is a relatively small detail overall, that is, regardless of whether path subclasses string or not, its addition in the standard library will be a step forward. Havind said that, I think the choice between subclassing or not is going to be a practicality-vs-purity decision. You're right, conceptually a path HAS_A string description, not IS_A string, so from a pure OO point of view, it should not inherit string. OTOH, people in favor of the subclassing point out the convenience for many (or most) common cases. It's a tradeoff, so arguments for both cases should be discussed. George -- http://mail.python.org/mailman/listinfo/python-list
