RE: Set and {} comparison confusion
From: Roman Yakovenko (roman.yakovenko_at_actimize.com)
Date: 09/09/04
- Next message: Brian Elmegaard: "Re: print and % operator"
- Previous message: Peter Hansen: "Re: print and % operator"
- Maybe in reply to: Roman Yakovenko: "Set and {} comparison confusion"
- Next in thread: Alex Martelli: "Re: Set and {} comparison confusion"
- Reply: Alex Martelli: "Re: Set and {} comparison confusion"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 9 Sep 2004 14:10:51 +0300 To: <python-list@python.org>
> -----Original Message-----
> From: Alex Martelli [mailto:aleaxit@yahoo.com]
>
>
> Roman Yakovenko <roman.yakovenko@actimize.com> wrote:
> ...
> > classes have __eq__, __ne__. Classes are mutable - I can't define
> > __hash__ function. __lt__ - I can implement but it will be
> meaningless.
>
> As long as it respects the fundamental semantics constraints such as:
> a < b and b < c imply a < c
> a < b implies not (a == b)
> a < b implies (a != b)
> not (a < a) for any a
> and so on, your __lt__will not be 'meaningless' but very useful.
Well I am not talking about algebra. Those rules are clear to me.
> Basically, __lt__ is meaningful if it's transitive,
> non-reflective, and
> compatible with your == and != (which I assume are compatible
> with each
> other); a transitive non-reflective < defines implicitly an
> equivalence
> relation, a eqv b <--> not (a < b or b < a), and you need your == to
> express exactly that equivalence relation... so if your == is
> meaningful, your < can't really be 'meaningless'!-)
I don't agree with you. I can compare properties of some object.
For example I can compare cows:
one python is longer then other ( length )
one python is heavier then other ( weight )
one python is older then other ( age )
But I can't define meaningful operator "<" on pythons.
I can compare pythons only property by property. I don't thing
that next code is meaningful
def __lt__( self, other_python ):
return self.length < other_python.length \
and self.weight < other_python.weight \
and self.age < other_python.age
I see this code as meaningless on python's.
> > Thank you for help. I think I have a dicision:
> > 1. I will implement meaningless __lt__
> > 2. I will sort ( I don't have duplicated items ) every time
> I need to compare
> > 2.1 Because sort is happen in place next time it will take
> less time to sort.
>
> Yes, that does seem to make sense to me. Once two lists without
> duplicates are sorted, they're equal as sets iff they're == as lists;
> and yes, maintaining sorted order is typically quite cheap in
> Python due
> to Tim Peters' powerful natural mergesort algorithm as implemented
> inside list.sort (though it might be worth having a look at the bisect
> module, it's likely going to be faster to just sort the lists each
> time).
>
>
> > Again - Thanks for help. It was very usefull. It seems that
> I had wrong
> expectation
> > from set - " unordered set collection based only on
> comparison operators".
> > My mistake.
>
> Ah, isn't set documented to need hashable elements? It should be. Of
> course, _why_ your class appears to be hashable when it defines __eq__
> and not __hash__ I dunno -- Python should diagnose that, but it does't
> appear to...
It is my fault too. All my classes derives from object. object do implements __hash__
function. I think I should raise exception if somebody tries to insert object into
set \ dictionary
> Alex
> --
> http://mail.python.org/mailman/listinfo/python-list
>
- Next message: Brian Elmegaard: "Re: print and % operator"
- Previous message: Peter Hansen: "Re: print and % operator"
- Maybe in reply to: Roman Yakovenko: "Set and {} comparison confusion"
- Next in thread: Alex Martelli: "Re: Set and {} comparison confusion"
- Reply: Alex Martelli: "Re: Set and {} comparison confusion"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
