PRE-PEP: new Path class; mutability, __hash__, __eq__, __cmp__

[Christoph Becker-Freyseng]

Gerrit Holl wrote:

> Christoph Becker-Freyseng wrote:
> 
>>Should Path be immutable like string?
> 
> 
> I have though about this, too. It should certainly not be fully mutable,
> because if a path changes, it changes. But maybe we could have a
> .normalise_inplace() which mutates the Path? What consequences would
> this have for hashability?
> 
> I like paths to be hashable. so they probably should be immutable.
> 
Yes. (already in the PEP)
While paths aren't strings they have a lot in common because paths (as I 
now think of them) are not directly associated with files. (Paths can be 
nonexistent or even invalid)

Moreover the basic operations like __eq__ shouldn't be reading methods ()!

__hash__ has to be compatible with __eq__.
hash(p1) == hash(p2)  <<<===   p1 == p2

Also
hash(p1) == hash(p2)  ===>>>   p1 == p2
should be true as far as possible.

I think
def __hash__(self):
	return hash(str(self.normalized()))
would do this fine.

So for __eq__ it follows naturaly
def __eq__(self, other):
	FIXME: isinstance checking
	return (str(self.normalized()) == str(other.normalized()))
It cares about nonexistent paths, too. (The samefile-solution won't --- 
we might code a special case for it ...)


What about __cmp__?
I've to admit that __cmp__ comparing the file-sizes is nice (__eq__= 
samefile is attractive, too --- they're both evil temptations :-) )

However __eq__ and __cmp__ returning possibly different results is odd.
Finaly implementing __cmp__ that way would make it a reading method and 
is problematic for nonexistent paths.

I'd like an implementation of __cmp__ which is more path specific than 
just string.__cmp__. But it should be consistent with __eq__.
Could we do something about parent and sub dirs?




Christoph Becker-Freyseng