PEP on path module for standard library

[Andrew Dalke]

George Sakkis wrote:
> That's why phone numbers would be a subset of integers, i.e. not every
> integer would correspond to a valid number, but with the exception of
> numbers starting with zeros, all valid numbers would be an integers.

But it's that exception which violates the LSP.

With numbers, if x==y then (x,y) = (y,x) makes no difference.
If phone numbers are integers then 001... == 01... but swapping
those two numbers makes a difference.  Hence they cannot be modeled
as integers.

> Regardless, this was not my point; the point was that adding
> two phone numbers or subtracting them never makes sense semantically.

I agree. But modeling them as integers doesn't make sense either.
Your example of adding phone numbers depends on them being represented
as integers.  Since that representation doesn't work, it makes sense
that addition of phone number is suspect.

> There are (at least) two frequently used path string representations,
> the absolute and the relative to the working directory. Which one *is*
> the path ? Depending on the application, one of them woud be more
> natural choice than the other.

Both.  I don't know why one is more natural than the other.

>> I trust my intuition on this, I just don't know how to justify it, or
>> correct it if I'm wrong.
> 
> My intuition also happens to support subclassing string, but for
> practical reasons rather than conceptual.

As you may have read elsewhere in this thread, I give some examples
of why subclassing from string fits best with existing code.

Even if there was no code base, I think deriving from string is the
right approach.  I have a hard time figuring out why though.  I think
if the lowest level Python/C interface used a "get the filename"
interface then perhaps it wouldn't make a difference.  Which means
I'm also more guided by practical reasons than conceptual.

				Andrew
				dalke at dalkescientific.com