Why keep identity-based equality comparison?

[Mike Meyer]

Re: Why keep identity-based equality comparison?

Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=blue]
> Op 2006-01-11, Mike Meyer schreef <mwm@mired.org> :[color=green]
>> Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=darkred]
>>> Op 2006-01-11, Mike Meyer schreef <mwm@mired.org> :
>>>> Antoon Pardon <apardon@forel. vub.ac.be> writes:
>>>>> Op 2006-01-10, Mike Meyer schreef <mwm@mired.org> :
>>>>>>> Now you can take the practical option and decide that programmaticall y
>>>>>>> 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.[/color]
>> That's a very silly thing to ask for. It presumes that all types are
>> the same. They aren't.[/color]
> It doesn't presume anything like that.[/color]

Yes it does. It presumes that all operators of all types either always
make sense, or there are always situations where they don't
[color=blue][color=green]
>> It also presumes that all comparisons are the same. They aren't.[/color]
> It doesn't presume that either.[/color]

Yes it does. It presumes that all operators either always make sesne,
or there are always situations where they don't.
[color=blue][color=green]
>> 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.[/color]
> Bad analogy since a fruit is not a relationship.[/color]

I suggest you look up the meaning of the word "analogy".
[color=blue][color=green]
>> 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.[/color]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
> 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.[/color]

But you can use a random function to decide no matter *how* the
bulitin relationships behave. That's part of the powero of Python - it
doesn't impose arbitrary constraints on what you can do. You seem to
think we should either disallow comparison operators from throwing
exceptions, or force them to throw exceptions under some unstated
conditions. But not all types are the same; some may not *have*
conditions under which all relational operators need to throw an
exception. And not all comparisons are the same; some may not *have*
conditions under which they need to throw an exception.
[color=blue][color=green][color=darkred]
>>>> 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.[/color]
>> 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.pytho n some years ago. What Guido proposed is inline with
>> the conclusions of those discussions.[/color]
> 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.[/color]

It's no easier for me to find them than for you to find them. And I'm
not guido - if you want his thoughts, you'll have to ask him.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Antoon Pardon]

Re: Why keep identity-based equality comparison?

Op 2006-01-12, Mike Meyer schreef <mwm@mired.org> :[color=blue]
> Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=green]
>> Op 2006-01-11, Mike Meyer schreef <mwm@mired.org> :[/color][/color]

[ 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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> algorithm on a container of them, but such an order is in general
>> less usefull than the superset ordering when you are manipulating
>> sets.[/color]
>
> And you're free to implement a subclass of sets that does that.[/color]

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.
[color=blue]
> 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.[/color]

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

[Mike Meyer]

Re: Why keep identity-based equality comparison?

Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=blue][color=green]
>> 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.[/color]
> What I argue is that there is no single order for a specific type.[/color]

I think that depends on your definition of type, but let it go.
[color=blue]
> There can be an order that is most usefull in general but which order
> is usefull at a specific point depends on the context.[/color]

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 <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Noam Raphael]

Re: Why keep identity-based equality comparison?

Mike Meyer wrote:[color=blue]
> spam.noam@gmail .com writes:
>[color=green]
>>try:
>> return a == b
>>except TypeError:
>> return a is b[/color]
>
>
> 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.[/color]

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.[color=blue]
>
> You're replacing "false" with an "emphatheti c false", that *all*
> containers to change for the worse to deal with it.
>[/color]
I don't see how they change for the worse if they have exactly the same
functionality and a few added lines of implementation.[color=blue]
>[color=green]
>>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.[/color]
>
>
> 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.[/color]

Again, "ugly" is a personal definition. I may call this "explicitne ss".
By the way, what's the "and so on" - I think that these are the only
built-in containers.[color=blue]
>
>[color=green]
>>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.[/color]
>
>
> 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[/color]

You can't create a general container with my proposed == behaviour.
That's what I meant.[color=blue]
>
>[color=green]
>>Also note that using the current behaviour, you can't easily
>>treat objects that do define a meaningful value comparison, by
>>identity.[/color]
>
>
> Yes you can. Just use the "is" operator.[/color]

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.[color=blue]
>
> Note that this behavior also has the *highly* pecular behavior that a
> doesn't necessarily equal a by default.[/color]

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".[color=blue]
>
> I will point out why your example usages aren't really usefull if
> you'll repeat your post with newlines.
>[/color]
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

[Mike Meyer]

Re: Why keep identity-based equality comparison?

Noam Raphael <spam.noam@gmai l.com> writes:[color=blue][color=green][color=darkred]
>>>Also note that using the current behaviour, you can't easily
>>>treat objects that do define a meaningful value comparison, by
>>>identity.[/color]
>> Yes you can. Just use the "is" operator.[/color]
> 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.[/color]

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.
[color=blue]
> Another example - you can't
> search for a specific list object in another list.[/color]

Your proposed == behavior doesn't change that at all.
[color=blue][color=green]
>> I will point out why your example usages aren't really usefull if
>> you'll repeat your post with newlines.[/color]
> 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).[/color]

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.
[color=blue]
> * 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.[/color]

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.
[color=blue]
> * 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.[/color]

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 <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Noam Raphael]

Re: Why keep identity-based equality comparison?

Mike Meyer wrote:[color=blue]
> Noam Raphael <spam.noam@gmai l.com> writes:
>[color=green][color=darkred]
>>>>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.[/color]
>>
>>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.[/color]
>
>
> 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.
>[/color]
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.[color=blue]
>[color=green]
>>Another example - you can't
>>search for a specific list object in another list.[/color]
>
>
> Your proposed == behavior doesn't change that at all.[/color]

It does - *use idlist*.[color=blue]
>
>[color=green][color=darkred]
>>>I will point out why your example usages aren't really usefull if
>>>you'll repeat your post with newlines.[/color]
>>
>>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).[/color]
>
>
> 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.
>[/color]
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.[color=blue]
>[color=green]
>>* 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 .[/color]
>
>
> 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.
>[/color]
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?)[color=blue]
>[color=green]
>>* 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.[/color]
>
>
> 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.
>[/color]
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

[Mike Meyer]

Re: Why keep identity-based equality comparison?

Noam Raphael <spam.noam@gmai l.com> writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> Noam Raphael <spam.noam@gmai l.com> writes:[color=darkred]
>>>>>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.[/color]
>> 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.[/color]
> 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).[/color]

No, I'm suggesting a general solution that works for *every* case
where you want something other than the standard equality case.
[color=blue]
> I'm suggesting the use of another container class: iddict instead of
> dict. That's all.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>>Another example - you can't
>>>search for a specific list object in another list.[/color]
>> Your proposed == behavior doesn't change that at all.[/color]
> It does - *use idlist*.[/color]

You're mixing two proposals into the same thread. You'll forgive me
for referring to the original proposal.
[color=blue][color=green][color=darkred]
>>>>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).[/color]
>> 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.[/color]
> 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.[/color]

So how come I can compare decimals to floats?
[color=blue][color=green][color=darkred]
>>> type(d)[/color][/color][/color]
<class 'decimal.Decima l'>[color=blue][color=green][color=darkred]
>>> d < 2.0[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>> d > 0.0[/color][/color][/color]
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.
[color=blue][color=green][color=darkred]
>>>* 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
>>>immediatel y.[/color]
>> 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.[/color]
> 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.[/color]

Exceptions are for finding *programming errors*? That's a rather
unusual view of exceptions.
[color=blue]
> 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?)[/color]

That try...except is the boilerplate I'm talking about.
[color=blue]
> 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.[/color]

But you're suggesting changing *far more* than just decimals, and have
made multiple suggestions. Exactly what are you looking for an example
of?

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Antoon Pardon]

Re: Why keep identity-based equality comparison?

Op 2006-01-14, Mike Meyer schreef <mwm@mired.org> :[color=blue]
> Antoon Pardon <apardon@forel. vub.ac.be> writes:[color=green][color=darkred]
>>> 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.[/color]
>> What I argue is that there is no single order for a specific type.[/color]
>
> I think that depends on your definition of type, but let it go.
>[color=green]
>> There can be an order that is most usefull in general but which order
>> is usefull at a specific point depends on the context.[/color]
>
> 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?[/color]

I did mention it, you even asked a use case and I gave it. What more
do you want?

--
Antoon Pardon