On Wed, 15 Jun 2011 19:00:07 -0700, Ethan Furman wrote:
> Thread 1: "objects of different types compare unequal" self:
> "nonsense! we have the power to say what happens in __eq__!"
>
> Thread 2: "objects that __hash__ the same *must* compare __eq__!" self:
> "um, what? ... wait, only immutable objects hash..."
Incorrect. And impossible. There are only a fixed number of hash values
(2**31 I believe...) and a potentially infinite number of unique, unequal
objects that can be hashed. So by the pigeon-hole principle, there must
be at least one pigeon-hole (the hash value) containing two or more
pigeons (unequal objects).
For example:
>>> hash(2**0 + 3)
4
>>> hash(2**64 + 3)
4
What you mean to say is that if objects compare equal, they must hash the
same. Not the other way around.
> Thread 2: "you're Path object is immutable..." self: "argh!"
>
> Here's the rub: I'm on Windows (yes, pity me...) but I prefer the
> unices, so I'd like to have / seperate my paths. But I'm on Windows...
Any sensible Path object should accept path components in a form
independent of the path separator, and only care about the separator when
converting to and from strings.
[...]
> So, I suppose I shall have to let go of my dreams of
>
> --> Path('/some/path/and/file') == '\\some\\path\\and\\file'
To say nothing of:
Path('a/b/c/../d') == './a/b/d'
Why do you think there's no Path object in the standard library? *wink*
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
