Re: Why keep identity-based equality comparison?
Op 2006-01-14, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. What I argue is that there is no single order for a specific type. I think that depends on your definition of type, but let it go. There can be an order that is most usefull in general but which order is usefull at a specific point depends on the context. Yes. So what? Does this fact suggest some change to Python that would improve it? If so, you need to mention it. If not, why bring it up at all? I did mention it, you even asked a use case and I gave it. What more do you want? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. What I argue is that there is no single order for a specific type. I think that depends on your definition of type, but let it go. There can be an order that is most usefull in general but which order is usefull at a specific point depends on the context. Yes. So what? Does this fact suggest some change to Python that would improve it? If so, you need to mention it. If not, why bring it up at all? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: [EMAIL PROTECTED] writes: try: return a == b except TypeError: return a is b This isn't easy. It's an ugly hack you have to use everytime you want to iterate through a heterogenous set doing equality tests. I wouldn't define this as an ugly hack. These are four simple line, which state clearly and precisely what you mean, and always work. I have seen ugly hacks in my life, and they don't look like this. You're replacing false with an emphathetic false, that *all* containers to change for the worse to deal with it. I don't see how they change for the worse if they have exactly the same functionality and a few added lines of implementation. Also, Mike said that you'll need an idlist object too - and I think he's right and that there's nothing wrong with it. Except that we now need four versions of internal data structures, instead of two: list, tuple, idlist, idtuple; set, idset, frozenset, frozenidset, and so on. What's wrong with this is that it's ugly. Again, ugly is a personal definition. I may call this explicitness. By the way, what's the and so on - I think that these are the only built-in containers. Note that while you can easily define the current == behaviour using the proposed behaviour, you can't define the proposed behaviour using the current behaviour. Yes you can, and it's even easy. All you have to do is use custom classes that raise an exception if they don't You can't create a general container with my proposed == behaviour. That's what I meant. Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Another example - you can't search for a specific list object in another list. Note that this behavior also has the *highly* pecular behavior that a doesn't necessarily equal a by default. Again, peculiar is your aesthethic sense. I would like to hear objections based on use cases that are objectively made more difficult. Anyway, I don't see why someone should even try checking if a==a, and if someone does, the exception can say this type doesn't support value comparison. Use the is operator. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. * It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. The third example applies to the Decimal==float use case, and for every type that currently has the default identity-based comparison and that may benefit from a value-based comparison. Take the class class Circle(object): def __init__(self, center, radius): self.center = center self.radius = radius Currently, it's equal only to itself. You may decide to define an equality operator which checks whether both the center and the radius are the same, but since you already have a default equality operator, that change would break backwards-compatibility. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Noam Raphael [EMAIL PROTECTED] writes: Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Wrong. All you have to do is create a list type that uses identity instead of value for equality testing. This is easier than mapping an exception to false. Another example - you can't search for a specific list object in another list. Your proposed == behavior doesn't change that at all. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). While I agree that Decimal(3.0) == 3.0 returning false doesn't make sense, having it raise an exception doesn't make any more sense. This should be fixed, but changing == doesn't fix it. * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. This isn't a use case. You don't get correct code with either version of '=='. While there is some merit to doing things that make errors easier to find, Python in general rejects the idea of adding boilerplate to do so. Your proposal would generate lots of boilerplate for many practical situations. * It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. Sorry, but that doesn't fly. If you have code that relies on the exception being raised when two types are compared, changing it to suddenly return a boolean will break that code. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: Noam Raphael [EMAIL PROTECTED] writes: Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Wrong. All you have to do is create a list type that uses identity instead of value for equality testing. This is easier than mapping an exception to false. You're suggesting a workaround, which requires me to subclass everything that I want to lookup by identity (and don't think it's simple - I will have to wrap a lot of methods that return a list to return a list with a modified == operator). I'm suggesting the use of another container class: iddict instead of dict. That's all. I don't think that mapping an exception to false is so hard (certainly simpler than subclassing a list in that way), and the average user won't have to do it, anyway - it's the list implementation that will do it. Another example - you can't search for a specific list object in another list. Your proposed == behavior doesn't change that at all. It does - *use idlist*. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). While I agree that Decimal(3.0) == 3.0 returning false doesn't make sense, having it raise an exception doesn't make any more sense. This should be fixed, but changing == doesn't fix it. No, it can't be fixed your way. It was decided on purpose that Decimal shouldn't be comparable to float, to prevent precision errors. I'm saying that raising an exception will make it clearer. * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. This isn't a use case. You don't get correct code with either version of '=='. While there is some merit to doing things that make errors easier to find, Python in general rejects the idea of adding boilerplate to do so. Your proposal would generate lots of boilerplate for many practical situations. I would say that there's a lot of merit to doing things that make errors easier to find. That's what exceptions are for. Please say what those practical situations are - that what I want. (I understand. You think that added containers and a try...except fro time to time aren't worth it. I think they are. Do you have any other practical situations?) * It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. Sorry, but that doesn't fly. If you have code that relies on the exception being raised when two types are compared, changing it to suddenly return a boolean will break that code. You are right, but that's the case for every added language feature (if you add a method, you break code that relies on an AttributeError...) You are right that I'm suggesting a try...except when testing if a list contains an object, but a case when you have a list with floats and Decimals, and you rely on Decimal(3.0) in list1 to find only Decimals seems to me a little bit far-fetched. If you have another example, please say it. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Noam Raphael [EMAIL PROTECTED] writes: Mike Meyer wrote: Noam Raphael [EMAIL PROTECTED] writes: Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Wrong. All you have to do is create a list type that uses identity instead of value for equality testing. This is easier than mapping an exception to false. You're suggesting a workaround, which requires me to subclass everything that I want to lookup by identity (and don't think it's simple - I will have to wrap a lot of methods that return a list to return a list with a modified == operator). No, I'm suggesting a general solution that works for *every* case where you want something other than the standard equality case. I'm suggesting the use of another container class: iddict instead of dict. That's all. You're suggesting adding a new builtin type to the language that deals with one special case. Is this special case really that common? I don't recall seeing anyone else ask for it in the last 10 years or so. I don't think that mapping an exception to false is so hard (certainly simpler than subclassing a list in that way), and the average user won't have to do it, anyway - it's the list implementation that will do it. I disagree with both your assessments. Subclassing is trivial. And every user who wants to compare elements in a container that might include heterogenous types has to deal with this issue. That's more than just lists, even if you only pay atttention to builtin types. Nuts - you have to deal with it when you're adding elements to a dictionary. Another example - you can't search for a specific list object in another list. Your proposed == behavior doesn't change that at all. It does - *use idlist*. You're mixing two proposals into the same thread. You'll forgive me for referring to the original proposal. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). While I agree that Decimal(3.0) == 3.0 returning false doesn't make sense, having it raise an exception doesn't make any more sense. This should be fixed, but changing == doesn't fix it. No, it can't be fixed your way. It was decided on purpose that Decimal shouldn't be comparable to float, to prevent precision errors. I'm saying that raising an exception will make it clearer. So how come I can compare decimals to floats? type(d) class 'decimal.Decimal' d 2.0 True d 0.0 False Are you proposing we should break this, which currently functions correctly? You're correct that this can't be fixed by fixing decimal alone. It requires more work than that. It may not be possible to fix this properly before Py3K. But your proposal can't be done until then anyway. I've already started the process of proposing a proper fix. * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. This isn't a use case. You don't get correct code with either version of '=='. While there is some merit to doing things that make errors easier to find, Python in general rejects the idea of adding boilerplate to do so. Your proposal would generate lots of boilerplate for many practical situations. I would say that there's a lot of merit to doing things that make errors easier to find. That's what exceptions are for. Exceptions are for finding *programming errors*? That's a rather unusual view of exceptions. Please say what those practical situations are - that what I want. (I understand. You think that added containers and a try...except fro time to time aren't worth it. I think they are. Do you have any other practical situations?) That try...except is the boilerplate I'm talking about. You are right that I'm suggesting a try...except when testing if a list contains an object, but a case when you have a list with floats and Decimals, and you rely on Decimal(3.0) in list1 to find only Decimals seems to me a little bit far-fetched. If you have another example, please say it. But you're suggesting
Re: Why keep identity-based equality comparison?
Op 2006-01-12, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: [ BIG CUT ] I'm going to drop this part. I disagree with you and think I can show some of your argument invalid. Hoever I also doubt something fruitfull can come from continuing this. Lets agree to disagree. IMO it would be better if it was possible to associate some kind of order function with the container. Because the order most usefull for comparing between two instances doesn't need to be the most usefull order in finding an element from a container. No, it wouldn't. Order relationships are a property of the type, not the container. The order relationships are right where they belong - attached to the type. Order relationships are only a property of the type in a particular sense. There certainly is not a one on one relationship between order relationships and types. A type can have multiple order relationships all usefull in different circumstances. If a specific order is only usefull in the context of a spefic container I see no problem with associating the order with the container. That notwithstanding, it's often practical to be able to override the order function for some specific method (and would be even if the order function were associated with the container instead of the type), so some of the methods that use order allow you to provide a function to use for them. If you really want a container type that has an order function associated with it, you can write one. If you want it made part of the language, you'll have to provide a use case. Fair enough. Take the heapqueue module. The times that I had need for a heapqueue this module was useless to me. The reason always boiled down to the fact that the order defined on the object (as far as there was one) was not the order in which I wanted the objects processed. e.g. I want a heapqueue of sets that gives priority according to the number of elements in the set. Or I have two heapqueues each of intervals. The first gives priority according to the low value, the second gives priority according the the high value. algorithm on a container of them, but such an order is in general less usefull than the superset ordering when you are manipulating sets. And you're free to implement a subclass of sets that does that. But that is not usefull to me. Take sets. It's been a while so I'm not sure I can dig it back up, but I once had an algorithm manipulating sets, where this manipulation would involve the normal superset order. This algorithm had two charateristics. 1) Manipulating certain sets, made the manipulation of other sets unnecessary. 2) Manipulating smaller sets was faster than manipulating larger sets. 3) Sets were constantly added and removed from the manipulating pool. These characteristics made this a natuaral candidate for a heapqueue that used the number of elements as (inverse) priority. However the manipulation of a single set needed the normal superset relationship as order relation. So making a subclass of sets with an order usefull for the heapqueue would only be a marginal improvement to the existing situation. If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. What I argue is that there is no single order for a specific type. There can be an order that is most usefull in general but which order is usefull at a specific point depends on the context. Sometimes this context is the container that the types belongs to, like a heapqueue. Associating that order with the container seems to most natural to treat this kind of circumstances. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. That's a very silly thing to ask for. It presumes that all types are the same. They aren't. It doesn't presume anything like that. It also presumes that all comparisons are the same. They aren't. It doesn't presume that either. To use an overworked analogy, you might as well ask that you either have to peel all fruit, or that you never have to peel a fruit. Bad analogy since a fruit is not a relationship. In any case, the proposeed behavior *is* consistent. The behavior for all builtin types will be that comparisons that don't make sense will throw exceptions. It is only consistent if you start from an inconsistent view and then check for how consistently this view is followed. There is nothing consistent in telling that 1 == (1,3) makes sense and 1 (1,3) doesn't make sense. Set theoretically both 1 and (1,3) are sets. There is a use case for things like 1 (1,3) making sense and denoting a total order. When you have a hetergenous list, having a total order makes it possible to sort the list which will make it easier to weed out duplicates. So why don't you demand a use case for the new behaviour to counter this use case? IMO it would be better if it was possible to associate some kind of order function with the container. Because the order most usefull for comparing between two instances doesn't need to be the most usefull order in finding an element from a container. I could impose a total order on sets, so that I can use a bisection algorithm on a container of them, but such an order is in general less usefull than the superset ordering when you are manipulating sets. Since we're talking about Py3K here, there is no default behavior. User-defined classes all inherit from builtin types, and will get the behavior of their comparison operators from those types. In particular, those that inherit from object will get objects behavior, which means they'll get equality as identity. But if this makes any behaviour defined on objects consistent by definition, because the only criteria you seem to have for consistency is the inherited behaviour from object. If object would use a random function to decide that would be consistent too, because it would be the behaviour inherited by other classes. I don't find this a usefull way to measure consistency. and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. Did you see examples that show why Guido wants things to behave whatever Guido's idea is a change from current behaviour. Each time I saw some argue a change here, people seem to expect a use case from that person. So why ask a use case of me and just accepy Guido's idea. For one thing, Guido has a long history of doing excellent Python design work. For another, this issue was thrashout out at length in comp.lang.python some years ago. What Guido proposed is inline with the conclusions of those discussions. Then it should be easy to come up with the use cases and arguments pro this idea presented then. If this idea of Guido was the result of his briliance in language design, surely there should be arguments and use cases to confirm that. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: There is a use case for things like 1 (1,3) making sense and denoting a total order. When you have a hetergenous list, having a total order makes it possible to sort the list which will make it easier to weed out duplicates. So why don't you demand a use case for the new behaviour to counter this use case? This could easily be handled with an alternate comparison function that you pass to the sort function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-12, Paul Rubin schreef http: Antoon Pardon [EMAIL PROTECTED] writes: There is a use case for things like 1 (1,3) making sense and denoting a total order. When you have a hetergenous list, having a total order makes it possible to sort the list which will make it easier to weed out duplicates. So why don't you demand a use case for the new behaviour to counter this use case? This could easily be handled with an alternate comparison function that you pass to the sort function. Yes that is true and will be all that is needed in most cases. But in the case where new items are regularly added, one might prefer to use the bisect module for something like this. The bisect module doesn't have an alternate comparison function neither has the heapqueue module. O.K. lets try to get at this from a more constructive direction. Python will get the behaviour that 1 (1,3) will throw an exception. What can python do to help for cases like the above. 1) Python could provide a seperare total ordering, maybe with operators like '|' and '|' and function operator.rank (with functionlity similar to cmp) 2) Python could make it possible to associate a ranking with a container. This ranking is used by default by methods and modules like sort, bisect and heapqueue. 3) Python could provide the possibility of providing an alternate comparison function with heapqueue, bisect and similar modules. These options are not meant to be exclusive. But if a choice is to be made I would prefer (2) (a little) over (1) over (3). -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: The bisect module doesn't have an alternate comparison function neither has the heapqueue module. They could be extended. Care to enter a feature request? 1) Python could provide a seperare total ordering, maybe with operators like '|' and '|' and function operator.rank (with functionlity similar to cmp) Based on experience that I'm sure you understand, anything like that is going to be awfully hard to sell. 3) Python could provide the possibility of providing an alternate comparison function with heapqueue, bisect and similar modules. That's probably the best bet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-12, Paul Rubin schreef http: Antoon Pardon [EMAIL PROTECTED] writes: The bisect module doesn't have an alternate comparison function neither has the heapqueue module. They could be extended. Care to enter a feature request? Not really because IMO this is the wrong approach. 1) Python could provide a seperare total ordering, maybe with operators like '|' and '|' and function operator.rank (with functionlity similar to cmp) Based on experience that I'm sure you understand, anything like that is going to be awfully hard to sell. 3) Python could provide the possibility of providing an alternate comparison function with heapqueue, bisect and similar modules. That's probably the best bet. But IMO not very helpfull. When I use a heapqueue I need to use it with the same comparison function through its whole lifetime. It doesn't make sense to work with a heapqueue that has a variable comparison function. So having to provide this comparison function with each operation strikes me as much to cumbersome and error prone. Especially if you are working with multiple heaps each with its own comparison function. Writing my own heapqueue class that takes a comparison function as a parameter to the __init__ method to associate with that particular heapqueue seems a more rational solution than extending (or letting others do so) the stdlib packages with such a parameter. IMO letting python associate such a function with an arbitrary container is the most usefull option. It would allow the programmer to easily define what they need. Do you only care about identity, provide a comparison function that works on identy. Do you want lst.index(1) to return the index of 1.0 and decimal(1) or not. You would be able to specify this just how you want by just associating a new comparison function with the container. Now off course I could write a subclass of list which would do all this, but that would mean writing a lot of the functionality that is basically already there. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. That's a very silly thing to ask for. It presumes that all types are the same. They aren't. It doesn't presume anything like that. Yes it does. It presumes that all operators of all types either always make sense, or there are always situations where they don't It also presumes that all comparisons are the same. They aren't. It doesn't presume that either. Yes it does. It presumes that all operators either always make sesne, or there are always situations where they don't. To use an overworked analogy, you might as well ask that you either have to peel all fruit, or that you never have to peel a fruit. Bad analogy since a fruit is not a relationship. I suggest you look up the meaning of the word analogy. In any case, the proposeed behavior *is* consistent. The behavior for all builtin types will be that comparisons that don't make sense will throw exceptions. It is only consistent if you start from an inconsistent view and then check for how consistently this view is followed. There is nothing consistent in telling that 1 == (1,3) makes sense and 1 (1,3) doesn't make sense. Set theoretically both 1 and (1,3) are sets. Of course there are types for which the given behaviors don't make sense. However, we're not talking about user-defined relations on user-defined types with syntax that isn't supported by the language. We're talking about the builtin relationships defined on the builtin types. There is a use case for things like 1 (1,3) making sense and denoting a total order. When you have a hetergenous list, having a total order makes it possible to sort the list which will make it easier to weed out duplicates. So why don't you demand a use case for the new behaviour to counter this use case? Yes, there is. And you are perfectly free to implement a type that behaves that way if you want to. I don't need a use case to counter this one; I just need to show that this use case can be reasonably covered by the proposed mechanism. IMO it would be better if it was possible to associate some kind of order function with the container. Because the order most usefull for comparing between two instances doesn't need to be the most usefull order in finding an element from a container. No, it wouldn't. Order relationships are a property of the type, not the container. The order relationships are right where they belong - attached to the type. That notwithstanding, it's often practical to be able to override the order function for some specific method (and would be even if the order function were associated with the container instead of the type), so some of the methods that use order allow you to provide a function to use for them. If you really want a container type that has an order function associated with it, you can write one. If you want it made part of the language, you'll have to provide a use case. I could impose a total order on sets, so that I can use a bisection algorithm on a container of them, but such an order is in general less usefull than the superset ordering when you are manipulating sets. And you're free to implement a subclass of sets that does that. If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. At least, it doesn't matter unless you try and force all the types and operators to be the same. Since we're talking about Py3K here, there is no default behavior. User-defined classes all inherit from builtin types, and will get the behavior of their comparison operators from those types. In particular, those that inherit from object will get objects behavior, which means they'll get equality as identity. But if this makes any behaviour defined on objects consistent by definition, because the only criteria you seem to have for consistency is the inherited behaviour from object. If object would use a random function to decide that would be consistent too, because it would be the behaviour inherited by other classes. I don't find this a usefull way to measure consistency. But you can use a random
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Christopher Subich schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]: I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. That a b returns false doesn't imply that a and b can be ranked. take sets. set([1,2]) and set([1,3)) can't be ranked but set([1,2]) set([1,3)) returns False just as set([1,2]) set([1,3)) does. Breaking my resolution already, but you're ignoring the fact that the set type uses the '' and '' operators from a set-theoretic, not number-theoretic point of view. That is irrelevant. the '' and '' symbols are usable to denote any mathematical order and are often enough used for even other order relations. The only reason that other symbols like the subset symbol are used is to avoid confusion about which order you are talking because numbers and sets are used together often enough. But the superset relationship is mathematically just as much an order relation as is the greater than relationship. Saying set(1,3) is greater than set(1,2) is meaningless (and not false), because the mathematical basis of the operator in this context is superset -- set(1,3) is a superset of set(1,2) is well-defined and false. No it is not meaningless. The superset relationship is just as much an order relationship and thus can mathematically make use of the '' and '' symbol just as any mathematical order relation can. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. The behavior proposed for Py3k *is* the practical route. It gives a reasonable behavior, and one that leads to simple implemenations for container operations. Then I have to ask, practical for who, user of python or the implementor, because I don't find it practical that a language says at the same times that two objects can use a comparision and can't. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Sure uses cases are interesting but if you always wait for a use case before implementing something, whatever the other arguments are, you will disappoint the future people with a use case because they can't do what they want yet. I haven't seen a case where testing for unequality throwing an exception would be actually usefull, yet that is considered, why do I have to provide a use case. BTW, the case you're arguing for is *different* from the case the OP proposed. By my reading, he wanted equality testing to throw an exception for two objects unless a comparison was explicitly coded. So that even a == a could cause an exception. Why not? If a is of a type where == is a meaningless operation then a == a is meaningless too. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Comparators - including equality comparators - can already throw exceptions. The enum case proved that. Your point? Your remark says nothing for or against python having two families of comparators, one that is defined as never throwing an exception and one defined as exception throwable. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? Again - give us real use cases. I didn't see a real use case for 1 (1,2) throwing an exception either. The only argument seems to be that the current behaviour confuses beginners. But I don't see that as such a strong argument because a number of other things confuse beginners too and are not up for a change. I also think that 1 == (1,2) returning False but 1 (1,2) throwing an excpetion masy not be that less confusing as the current behaviour. I don't care that much what it will be, but I would prefer a consistent approach for all comparators. No either all throw an exception when the two operands are of differnt type or None does (or two families) I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. Floats *are* a discrete type. The equality *relationship* is what's fuzzy. There are lots of non-transitive relationships around. I don't find them wierd at all. That there are a lot of non-transitive relationships and that there is nothing weird about them, says nothing about one specific relationship, == which normaly is considered to be transitive and turns out not to be. Beside I think the == comparison is transitive on the floats. It is just that if you do your calculations that the imprecision in the numbers can give you a result that give false where you expect true when comparing for equality, but that is because you
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. Did you see examples that show why Guido wants things to behave whatever way he wants? I didn't and I didn't see examples from you either. Guido's idea is a change from current behaviour. Each time I saw some argue a change here, people seem to expect a use case from that person. So why ask a use case of me and just accepy Guido's idea. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. That's a very silly thing to ask for. It presumes that all types are the same. They aren't. It also presumes that all comparisons are the same. They aren't. To use an overworked analogy, you might as well ask that you either have to peel all fruit, or that you never have to peel a fruit. In any case, the proposeed behavior *is* consistent. The behavior for all builtin types will be that comparisons that don't make sense will throw exceptions. Since we're talking about Py3K here, there is no default behavior. User-defined classes all inherit from builtin types, and will get the behavior of their comparison operators from those types. In particular, those that inherit from object will get objects behavior, which means they'll get equality as identity. and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. Did you see examples that show why Guido wants things to behave whatever Guido's idea is a change from current behaviour. Each time I saw some argue a change here, people seem to expect a use case from that person. So why ask a use case of me and just accepy Guido's idea. For one thing, Guido has a long history of doing excellent Python design work. For another, this issue was thrashout out at length in comp.lang.python some years ago. What Guido proposed is inline with the conclusions of those discussions. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: Steven Bethard writes: Not to advocate one way or the other, but how often do you use heterogeneous containers? Pretty much everything I do has heterogenous containers of some sort or another. Sorry, I should have been a little more specific. I meant heterogeneous containers where you've used the in operator. SQL queries made to DP API compliant modules return homogenous lists of heterogenous containers. The cgi module turns the request string into a dictionary-like container of objects with values of different types. Are the keys of different types too? Because if the keys are all the same types, then using the in operator here wouldn't raise an exception. Unless, of course, you used the in operator on the .values() of the dictionary... The last thing I did that was both more than a script and didn't use either a database or a web front end was (IIRC) a media player for multiple media types. It revolved around lists of things to play, and the things in question could be any playable object - video or audio files, track on a CD, or a DVD, or even a playlist. That seems pretty reasonable. Your code used the in operator with these lists? Come to think of it, recursive data structures of this type - a container that contains a heterogenous list of things, possibly including instances of the container type itself - are pretty common. Sure. I have a number of tree-like containers, and in at least a few implementations, BranchNode and LeafNode are different classes. But I haven't needed the in operator with these. With the raise-exceptions-between-objects-of-different-types proposal, it would probably raise an exception if you tried, but I can't decide whether that's a good or a bad thing... The other proposal - if I have it right - would not change the behavior of equality comparisons between objects of the same class, but would make comparisons between objects of different classes raise an exception instead of returning false by default. Perhaps, given duck-typing, a better proposal would be to raise an exception if the objects have different interfaces. Of course, at the moment, I can't think of any even vaguely efficient way of checking that. ;-) STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Steven Bethard [EMAIL PROTECTED] writes: Mike Meyer wrote: Steven Bethard writes: Not to advocate one way or the other, but how often do you use heterogeneous containers? Pretty much everything I do has heterogenous containers of some sort or another. Sorry, I should have been a little more specific. I meant heterogeneous containers where you've used the in operator. Fair enough. But the problem occurs with more than just the in operator. Anytime you want to do comparisons on objects in a heterogenous container, you have to deal with this. This includes other methods on the container, like list index and remove moethods. It also means that application-level code that does these kinds of things have to deal with the possible exceptions as non-exceptional occurences. Yeah, there's an easy fix. But it's ugly. SQL queries made to DP API compliant modules return homogenous lists of heterogenous containers. The cgi module turns the request string into a dictionary-like container of objects with values of different types. Are the keys of different types too? Because if the keys are all the same types, then using the in operator here wouldn't raise an exception. Unless, of course, you used the in operator on the .values() of the dictionary... Nope, not different keys. The canonical example of that would be the many memoize decorators. Note that *inserting* something into such a dictionary can cause problems, as if two objects hash to the same value, they get compared for equality. The last thing I did that was both more than a script and didn't use either a database or a web front end was (IIRC) a media player for multiple media types. It revolved around lists of things to play, and the things in question could be any playable object - video or audio files, track on a CD, or a DVD, or even a playlist. That seems pretty reasonable. Your code used the in operator with these lists? I don't really recall - it's been a while. I know I provided searching facillities, but don't recall if it did a search by doing object comparisons or not. Come to think of it, recursive data structures of this type - a container that contains a heterogenous list of things, possibly including instances of the container type itself - are pretty common. Sure. I have a number of tree-like containers, and in at least a few implementations, BranchNode and LeafNode are different classes. But I haven't needed the in operator with these. With the raise-exceptions-between-objects-of-different-types proposal, it would probably raise an exception if you tried, but I can't decide whether that's a good or a bad thing... Ugh. That's *ugly*. That means you have to do a complete pass over the data to figure out if two objects are different types or not so you can decide to raise the exception. Whether you want to make a seperate check the type pass or try doing equality tests at the same time will depend on the data. If you're checking a set of 10-million element lists, you *don't* want to check them all if you can avoid it. Either that, or make the results of the in operator (and related methods, etc.) depend on the comparison order. That might be acceptable for lists, but it's really not for sets or dictionaries. Actually, that's not sufficient to make the results reliable. If some objects are allowed to *not* throw exceptions and do equality-based-on-identity, then the results of a == b won't be the same as the results of b == a, so looking for a in a container that has b in it will give different results than looking for b in a container that has a in it. The other proposal - if I have it right - would not change the behavior of equality comparisons between objects of the same class, but would make comparisons between objects of different classes raise an exception instead of returning false by default. Perhaps, given duck-typing, a better proposal would be to raise an exception if the objects have different interfaces. Of course, at the moment, I can't think of any even vaguely efficient way of checking that. ;-) Yup. This *really* looks like trying to enforce static typing in a language that doesn't do anything like it now. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'd say breaking that is a bad thing. But if you don't break that, then having x == y raise an exception for user classes seems wrong. The comparison should be False unless they are the same object - which is exactly what equality based on id gives us. Seconded. All hell would break loose if Python didn't allow == for heterogenous types, $DEITY only knows how many types I relied on it. Please don't let it go in Py3k. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Maybe that is just a wrong implementation of the in operator. One may agree on a protocol for the in operator to catch the TypeError when it tests for equality and treating the raised exception the same as the two elements not being equal. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'm not that sure about the intuitively. The author of the Enum class didn't seem to find it that intuitive to just name one counter example. IMO x == y turning up false when uncomparable is just as intuitive as x y turning up false when uncomparable but a lot of people don't seem to agree with the latter. My impression is that what is intuitive may vary wildly here. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. I think such cases can be troublesome too for containers and the in operator. IMO some more thinking about this is needed before deciding this would be a good idea or not. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Maybe that is just a wrong implementation of the in operator. That's what I said just below: You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. It is broken in the context of the current python behaviour. In a different context with different behaviour of containers such behaviour may very well be the most intuitive. We are now talking about python3k and so such we should be open to the possibility that what is broken in current python may very well be desirable behaviour for what python will evolve into. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. If you take the first choice you are right that comparing for equality is never meaningless, but so is using the other comparisons. If two objects are not comparable then we just have that a b, a ==b and a b are all false. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? Well not with the in operator but with the index method of lists which seems related enough. If the in operator returns true one can use index to find out an element in the container that compares equal. Now normally it wouldn't make a difference whether you would make further comparisons against the original object or against the object in the list. But in this case it can make a difference and it isn't obvious what one should do. IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really, id({}) id([]).
He also said that default equality comparison will continue to be
identity-based. This means that x == y will never raise an exception,
as is the situation is now. Here's his reason:
Let me construct a hypothetical example: suppose we represent a car
and its parts as objects. Let's say each wheel is an object. Each
wheel is unique and we don't have equivalency classes for them.
However, it would be useful to construct sets of wheels (e.g. the set
of wheels currently on my car that have never had a flat tire). Python
sets use hashing just like dicts. The original hash() and __eq__
implementation would work exactly right for this purpose, and it seems
silly to have to add it to every object type that could possibly be
used as a set member (especially since this means that if a third
party library creates objects for you that don't implement __hash__
you'd have a hard time of adding it).
Now, I don't think it should be so. My reason is basically explicit is
better than implicit - I think that the == operator should be reserved
for value-based comparison, and raise an exception if the two objects
can't be meaningfully compared by value. If you want to check if two
objects are the same, you can always do x is y. If you want to create
a set of objects based on their identity (that is, two different
objects with the same value are considered different elements), you
have two options:
I often want to be able to ask, is one object equal to another, where
they *might* be of the same type or notr.
If they aren't of the same type, then the answer to :
a == b
is obviously False. Otherwise I have to wrap the test in a
``try...except`` block or compare type (and possibly then compare
value). Both of which are more verbose.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Fuzzyman schreef [EMAIL PROTECTED]:
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really, id({}) id([]).
He also said that default equality comparison will continue to be
identity-based. This means that x == y will never raise an exception,
as is the situation is now. Here's his reason:
Let me construct a hypothetical example: suppose we represent a car
and its parts as objects. Let's say each wheel is an object. Each
wheel is unique and we don't have equivalency classes for them.
However, it would be useful to construct sets of wheels (e.g. the set
of wheels currently on my car that have never had a flat tire). Python
sets use hashing just like dicts. The original hash() and __eq__
implementation would work exactly right for this purpose, and it seems
silly to have to add it to every object type that could possibly be
used as a set member (especially since this means that if a third
party library creates objects for you that don't implement __hash__
you'd have a hard time of adding it).
Now, I don't think it should be so. My reason is basically explicit is
better than implicit - I think that the == operator should be reserved
for value-based comparison, and raise an exception if the two objects
can't be meaningfully compared by value. If you want to check if two
objects are the same, you can always do x is y. If you want to create
a set of objects based on their identity (that is, two different
objects with the same value are considered different elements), you
have two options:
I often want to be able to ask, is one object equal to another, where
they *might* be of the same type or notr.
If they aren't of the same type, then the answer to :
a == b
is obviously False. Otherwise I have to wrap the test in a
``try...except`` block or compare type (and possibly then compare
value). Both of which are more verbose.
If we are going to stick to one equal comparator then there will
always be cases that seem to be more verbose than needed. In the
case where you consider it an error if you are working with objects
of different classes you now have to expicitely test for unequal
types and raise an exception explicitly which is also more verbose.
IMO if they aren't of the same type then the answer to:
a b
is just as obviously False as
a == b
Yet how things are proposed now, the first will throw an exception
and the latter will return False.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]: On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. That a b returns false doesn't imply that a and b can be ranked. take sets. set([1,2]) and set([1,3)) can't be ranked but set([1,2]) set([1,3)) returns False just as set([1,2]) set([1,3)) does. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. But we don't say the latter. What we do say is that one is 'not greater than' and 'not lesser than' (and 'not equal to') the other. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon wrote: Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]: I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. That a b returns false doesn't imply that a and b can be ranked. take sets. set([1,2]) and set([1,3)) can't be ranked but set([1,2]) set([1,3)) returns False just as set([1,2]) set([1,3)) does. Breaking my resolution already, but you're ignoring the fact that the set type uses the '' and '' operators from a set-theoretic, not number-theoretic point of view. Saying set(1,3) is greater than set(1,2) is meaningless (and not false), because the mathematical basis of the operator in this context is superset -- set(1,3) is a superset of set(1,2) is well-defined and false. Set uses '' and '' because the superset and subset symbols aren't on the keyboard. In languages that allow operator overloading, there are always some well-defined cases where the operator is the simplest, clearest notation yet the operator has a meaning very distinct from the arithmetical operation. As another example, Pyparsing uses '' to load a Forward declaration, for recursive grammars -- this obviously has nothing to do with bit-shifting. Of course, cases like these two are fairly textbook examples for the argument that operator overloading is unclear; Python accepts the occasional ambiguity and allows (indeed encourages, to a reasonable degree) operator overloading for conciseness and expressiveness. To reply to your other argument, Antoon: Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. [snip] I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). I personally feel that the use cases for this other comparison (===?) are very restricted. In fact, your example itself isn't even a use-case for this operator, because integer/float/decimal have well-defined equality comparisons already (that explicitly account for different types) -- the implicit not is implies !=, if __eq__ isn't defined behaviour isn't triggered. The use-case for a === operator would seem to be restricted to when program behaviour is determined soley by a not equalling b. If a wrong object is referenced by b, then the program might do a Bad Thing, because it expects b to be something else... except that the error would be caught later anyway -- probably by calling b.method() or somesuch. In fact, even in more esoteric cases the behaviour of == as-is is useful; in the itertools.izip_longest discussion, this behaviour is implicitly used in the sentinel-stopping method (izip(chain(iter,sent),chain(iter,sent),...,stop=(sent,sent,sent,...)), to badly mangle the syntax). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Peter Decker wrote: On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. I agree. If a and b are of incomparable types, then a != b is True but a b is meaningless. All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. The behavior proposed for Py3k *is* the practical route. It gives a reasonable behavior, and one that leads to simple implemenations for container operations. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? BTW, the case you're arguing for is *different* from the case the OP proposed. By my reading, he wanted equality testing to throw an exception for two objects unless a comparison was explicitly coded. So that even a == a could cause an exception. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Comparators - including equality comparators - can already throw exceptions. The enum case proved that. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? Again - give us real use cases. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. Floats *are* a discrete type. The equality *relationship* is what's fuzzy. There are lots of non-transitive relationships around. I don't find them wierd at all. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? Well not with the in operator but with the index method of lists which seems related enough. The index method of list is already a bit fuzzy. If the in operator returns true one can use index to find out an element in the container that compares equal. Now normally it wouldn't make a difference whether you would make further comparisons against the original object or against the object in the list. But in this case it can make a difference and it isn't obvious what one should do. That's because in this case there's no on right answer. What you should do will depend on what you are trying to accomplish. That's the normal state of affairs when programming. IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). That's an argument for a more *precise* equality operator. That's certainly worth considering, but has nothing to do with whether or not it makes sense for an equality comparison to throw an exception. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Can you provide a case where having a test for equality throw an exception is actually useful? Yes. It will be useful because: 1. The bug of not finding a key in a dict because it was implicitly hashed by identity and not by value, would not have happened. 2. You wouldn't get the weird 3.0 != Decimal(3.0) - you'll get an exception which explains that these types aren't comparable. 3. If, in some time, you will decide that float and Decimal could be compared, you will be able to implement that without being concerned about backwards compatibility issues. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? Again - give us real use cases. You may catch bugs earlier - say you have a multidimensional array, and you forgot one index. Having comparison raise an exception because type comparison is meaningless, instead of returning False silently, will help y! ou catch your problem earlier. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
It seems to me that both Mike's and Fuzzyman's objections were that sometimes you want the current behaviour, of saying that two objects are equal if they are: 1. the same object or 2. have the same value (when it's meaningful). In both cases this can be accomplished pretty easily: You can do it with a try..except block, and you can write the try...except block inside the __contains__ method. (It's really pretty simple: try: return a == b except TypeError: return a is b ) Also, Mike said that you'll need an idlist object too - and I think he's right and that there's nothing wrong with it. Note that while you can easily define the current == behaviour using the proposed behaviour, you can't define the proposed behaviour using the current behaviour. Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Also note that in the cases that you do want identity-based behaviour, defining it explicitly can result in a more efficient program: explicit identity-based dict doesn't have to call any __hash__ and __eq__ protocols - it can compare the pointers themselves. The same if you want to locate a specific object in a list - use the proposed idlist and save yourself O(n) value-based comparisons, which might be heavy. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
[EMAIL PROTECTED] writes: It seems to me that both Mike's and Fuzzyman's objections were that sometimes you want the current behaviour, of saying that two objects are equal if they are: 1. the same object or 2. have the same value (when it's meaningful). In both cases this can be accomplished pretty easily: You can do it with a try..except block, and you can write the try...except block inside the __contains__ method. (It's really pretty simple: try: return a == b except TypeError: return a is b ) This isn't easy. It's an ugly hack you have to use everytime you want to iterate through a heterogenous set doing equality tests. You're replacing false with an emphathetic false, that *all* containers to change for the worse to deal with it. Also, Mike said that you'll need an idlist object too - and I think he's right and that there's nothing wrong with it. Except that we now need four versions of internal data structures, instead of two: list, tuple, idlist, idtuple; set, idset, frozenset, frozenidset, and so on. What's wrong with this is that it's ugly. Note that while you can easily define the current == behaviour using the proposed behaviour, you can't define the proposed behaviour using the current behaviour. Yes you can, and it's even easy. All you have to do is use custom classes that raise an exception if they don't Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Note that this behavior also has the *highly* pecular behavior that a doesn't necessarily equal a by default. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: [EMAIL PROTECTED] writes: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Not to advocate one way or the other, but how often do you use heterogeneous containers? I couldn't find any in my (admittedly small) codebase. Could you post some examples of what kind of problems lend themselves to being solved by heterogeneous containers? Thanks, STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Steven Bethard [EMAIL PROTECTED] writes: Not to advocate one way or the other, but how often do you use heterogeneous containers? Pretty much everything I do has heterogenous containers of some sort or another. SQL queries made to DP API compliant modules return homogenous lists of heterogenous containers. The cgi module turns the request string into a dictionary-like container of objects with values of different types. Higher-level web interfaces go even further in this direction. The last thing I did that was both more than a script and didn't use either a database or a web front end was (IIRC) a media player for multiple media types. It revolved around lists of things to play, and the things in question could be any playable object - video or audio files, track on a CD, or a DVD, or even a playlist. Come to think of it, recursive data structures of this type - a container that contains a heterogenous list of things, possibly including instances of the container type itself - are pretty common. Pretty much every GUI package has something like it. All processors of SGML-based markup languages I've ever dealt with included something like it. MIME-encoded email does this. Page layout programs do this. Block-structured programming languages do this. And probably lots of others. These are things that in a language that used classes for carrying (and enforcing) type, all of these cases would be heterogenous lists of objects that were subtypes of some type, so maybe they would really be heterogenous. But then you're stuck with the interesting question: What's the type relationship between two objects a and b that allows them to be compared. This question is still interesting with duck typing. If anything, it's even more interesting. We have *at least two* different proposals for a different typing system in hand. For one, the answer is obvious. The OP proposed that equality only be allowed when the types explicitly allow it, instead of defaulting to typing by identity. In that one the answer is that all the types on the list have to boilerplate so they play together. Phrasing it that way makes it seem contrary to the spirit of Python, as not needing boilerplat is an oft-touted strength of Python. The other proposal - if I have it right - would not change the behavior of equality comparisons between objects of the same class, but would make comparisons between objects of different classes raise an exception instead of returning false by default. Since I didn't raise this proposal, I'll leave it up to someone else to explain under what conditions two objects that are both instances of some class are the same type or not. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
[EMAIL PROTECTED] writes: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'd say breaking that is a bad thing. But if you don't break that, then having x == y raise an exception for user classes seems wrong. The comparison should be False unless they are the same object - which is exactly what equality based on id gives us. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
