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? -- http://mail.python.org/mailman/listinfo/python-list
