Path inherits from basestring again

[Carl Banks]

Reinhold Birkenfeld wrote:
> Peter Hansen wrote:
> > Reinhold Birkenfeld wrote:
> >> One thing is still different, though: a Path instance won't compare to a regular
> >> string.
> >
> > Could you please expand on what this means?  Are you referring to doing
> > < and >= type operations on Paths and strings, or == and != or all those
> > or something else entirely?
>
> All of these. Do you need them?

[snip]

> At the moment, I think about overriding certain string methods that make
> absolutely no sense on a path and raising an exception from them.


Ick.  This reeks of the sort of hubris from people who think they
anticipate all valid uses of something.

Is it a basestring or not?  If it is, then let it be a basestring.  It
is unreasonable to want to format a pathame for printing?  We might
want to retain ljust and friends.  Maybe there's a filenaming scheme
where files are related by having a character changed here or there.
So we might want to iterate though the characters in a pathname.  How
do you know how people are going to use it?  We're all supposed to be
adults here.

Let me suggest that wanting to remove all these methods/operations
suggests that one doesn't really think it ought to be a basestring.
The way I see it, the only compelling reason for it to be a basestring
is to accommodate poorly designed functions that test whether an
argument is a filename or a file object using isinstance(basestring,x)
on it.  But the best thing to do is fix those interfaces, and let path
be what it should be, and not a hack to accommodate poor code.


-- 
CARL BANKS