On Wed, 18 Jan 2006 17:10:09 +0100 Claudio Grondi <[EMAIL PROTECTED]> wrote: > or when the objects being members of the list redefine > __eq__ so, that no matter how different they are, the > lists always compare True.
If those objects have redefined __eq__ so that they are all equal in value to each other, then this is quite intuitive, although not necessarily very useful -- the author of the objects is saying that "one is as good as another". I can't think of any kind of object for which such a definition of value would be useful. But in the real world ... Lets consider a real example. Suppose I have a variety of "fill level" indicators (class 'fl' below). They may contain, let's say, a numerical value and a unit of liquid measure (and probably an epsilon for float comparisons, BTW): >>> a = fl(1.04, 'pint') >>> b = fl(1.00, 'liter') >>> a == b True >>> a = [fl(1.04,'pint')] >>> b = [fl(1.00,'liter')] >>> a == b True (Not tested, because I'm not going to waste time writing fl right now!) The point is, the author of this hypothetical 'fl' class wants its value to be isomorphic to the amount of liquid its representation would contain, regardless of choice of units (and probably to within a reasonable experimental error to take care of float precision). The author of a class has the power to DEFINE what "value" is in Python. And that is an extremely useful capability. If the interpreter were to impose this definition (which is what you seem to be asking for when you complain that "value" has no meaning in Python), that would terribly reduce the utility of Python. In general, the use of "value" (that is, "value" distinct from "identity") implies that some kind of math is going to be done with the objects. This is true even with strings, in that comparison and other operators are defined with respect to them, and depend on their literal value (not their identity as an object in memory). If objects NEED to only be compared by identity, then they should leave __eq__ alone and identity will be used when they are compared. -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
