PEP on path module for standard library

[George Sakkis]

"Andrew Dalke" <dalke at dalkescientific.com> wrote:

> George Sakkis wrote:
> > 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.
>
> How did you decide it's "has-a" vs. "is-a"?
>
> All C calls use a "char *" for filenames and paths,
> meaning the C model file for the filesystem says
> paths are strings.

Bringing up how C models files (or anything else other than primitive types for that matter) is not
a particularly strong argument in a discussion on OO design ;-)

> Paths as strings fit the Liskov substitution principle
> in that any path object can be used any time a
> string is used (eg, "loading from " + filename)

Liskov substitution principle imposes a rather weak constraint on when inheritance should not be
used, i.e. it is a necessary condition, but not sufficient. Take for example the case where a
PhoneNumber class is subclass of int. According to LSP, it is perfectly ok to add phone numbers
together, subtract them, etc, but the result, even if it's a valid phone number, just doesn't make
sense.

> Good information hiding suggests that a better API
> is one that requires less knowledge.  I haven't
> seen an example of how deriving from (unicode)
> string makes things more complicated than not doing so.

I wouldn't say more complicated, but perhaps less intuitive in a few cases, e.g.:

> path(r'C:\Documents and Settings\Guest\Local Settings').split()
['C:\\Documents', 'and', 'Settings\\Guest\\Local', 'Settings']
instead of
['C:', 'Documents and Settings', 'Guest', 'Local Settings']

I just noted that conceptually a path is a composite object consisting of many properties (dirname,
extension, etc.) and its string representation is just one of them. Still, I'm not suggesting that a
'pure' solution is better that a more practical that covers most usual cases.

George