- From: Fred L. Drake <fdrake@cnri.reston.va.us>
- Date: Tue, 15 Dec 1998 09:37:52 -0500 (EST)
- To: John Cowan <cowan@locke.ccil.org>
- Cc: DOM List <www-dom@w3.org>, xml-sig@python.org
John Cowan writes: > The trouble with that scheme is that it makes equality hard to > reason about. Intuitively, we expect equality to be transitive, > (if a = b and b = c then a = c), reflexive (a = a), and symmetrical > (if a = b then b = a). Making equality depend on mutable properties > defeats this: a might = b at one time, but a later check for > b = a might fail. That is correct. This is very important for the programmer to know about, and is a real consideration when designing a class for which equality or ordering are important issues. This is one reason why many Python programmers use a minimalist approach for immutable data: it's clear that a particular value will not change underneath you. However, I don't think comparison of mutable objects is necessarily a signigicant problem. I think most programmers expect equality of objects to be meaning only when the comparison is made; any longevity of the result depends on the specific guarantees made by that object. > > a.reverse() > > I presume this is a *destructive* reverse (leaves a reversed)? Yes, that's exactly how the list .reverse() method operates.. I think we're sufficiently off-topic; we can move this to personal email or some other forum if you wish to continue. The topic is interesting. This might be good for comp.lang.python. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Received on Tuesday, 15 December 1998 10:46:21 UTC