Set and {} comparison confusion

[Roman Yakovenko]

> -----Original Message-----
> From: Roman Yakovenko 
> Sent: Thursday, September 09, 2004 2:11 PM
> To: python-list at python.org
> Subject: RE: Set and {} comparison confusion
> 
> 
> 
> > -----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:
                            ^^^^^ pythons :-)

>  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
> > 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>