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
