[path-PEP] Path inherits from basestring again
rrr at ronadam.com
Mon Aug 1 22:00:30 CEST 2005
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.
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?
More information about the Python-list