Set and {} comparison confusion

[Roman Yakovenko]

> -----Original Message-----
> From: Alex Martelli [mailto:aleaxit at yahoo.com]
> 
> 
> Roman Yakovenko <roman.yakovenko at 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
>