PRE-PEP: new Path class; mutability, __hash__, __eq__, __cmp__
webmaster at beyond-thoughts.com
Fri Jan 9 00:22:43 CET 2004
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
hash(p1) == hash(p2) ===>>> p1 == p2
should be true as far as possible.
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?
More information about the Python-list