[path-PEP] Path inherits from basestring again

[Ron Adam]

Ivan Van Laningham wrote:


>>People can subclass Path and add it if they really want it.  They can use
>>Jason's original module.  My position is that the PEP without this use of
>>__div__ is (a) better as a standard module, and (b) improves the chance of
>>the PEP being accepted.
>>
> 
> 
> I disagree.  Using __div__ to mean path concatenation is no worse than
> using __add__ to mean string concatenation, ....

But '+' doesn't mean string concatenation, it means (calls the __add__ 
method) which when used with objects other than numeric types is usually 
an object join method.  It only means string concatenation when used 
with string objects.

In this case a path object is a string object that behaves somewhat like 
a list and somewhat like a string depending on how it's being accessed. 
  Maybe a string class isn't the best way to store a path.  It seems to 
me a list with string elements would work better.  I'm not sure why it 
was ruled out.  Maybe someone could clarify that for me.

I think it's a mistake to define '+' literally to mean string 
concatenation.  I believe the '/' will be considered a wart by many and 
a boon by others.  If I'm right, there will be endless discussions over 
it if it's implemented.  I'd rather not see that, so I'm still -1 
concerning '/' for that reason among others.


Cheers,
Ron

PS. Could someone repost the links to the current pre-pep and the most 
recent module version so I can look at it closer look?