In article <[EMAIL PROTECTED]>, "A.T.Hofkamp" <[EMAIL PROTECTED]> wrote:
> In object oriented programming, objects are representations of values, and the > system shouldn't care about how many instances there are of some value, just > like numbers in math. Every instance with a certain value is the same as every > other instance with the same value. Whether two things are equal depends on the context. Is one $10 note equal to another? It depends. If the context is a bank teller making change, then yes, they are equal. What's more, there are lots of sets of smaller notes which would be equally fungible. If the context is a district attorney showing a specific $10 note to a jury as evidence in a drug buy-and-bust case, they're not. It's got to be exactly that note, as proven by a recorded serial number. In object oriented programming, objects are representations of the real world. In one case, the $10 note represents some monetary value. In another, it represents a piece of physical evidence in a criminal trial. Without knowing the context of how the objects are going to be used, it's really not possible to know how __eq__() should be defined. Let me give you a more realistic example. I've been doing a lot of network programming lately. We've got a class to represent an IP address, and a class to represent an address-port pair (a "sockaddr"). Should you be able to compare an address to a sockaddr? Does 192.168.10.1 == 192.168.10.1:0? You tell me. This is really just the "does 1 == (1 + 0j)" question in disguise. There's reasonable arguments to be made on both sides, but there is no one true answer. It depends on what you're doing. -- http://mail.python.org/mailman/listinfo/python-list
