comparison with None

[Alex Martelli]

Re: comparison with None

Tommy Grav <tgrav@mac.comw rote:

On Apr 19, 2007, at 11:00 PM, Alex Martelli wrote:
>

Alan Isaac <aisaac@america n.eduwrote:

currently documented behavior:
"objects of different types always compare unequal".

Where is that documented? URL please?

>>1.0 == 1

True

>>type(1.0), type(1)

(<type 'float'>, <type 'int'>)

>
Isn't this an example of numerical comparison (= or !=) versus
object comparison (is or is not). I think the documentation needs
to state that there is a difference between the two types.

Operator == (TWO equal signs, not just one: that would be an assignment
instead) can be applied to arbitrary objects, not just numbers, just
like operator 'is'.

>>u'ciao' == 'ciao'

True

>>type(u'ciao') , type('ciao')

(<type 'unicode'>, <type 'str'>)

See, it's not a question of numbers versus other things: the
distinction, rather, is between comparison of the values of objects
(which can perfectly well be equal even for objects of different types)
versus checking object identity (and since an object only has one type
at a time, it can't be "the same object" as one with a different type).
Why do you think the Python docs don't draw the difference between '=='
(equality) and 'is' (identity)?

I'm still interested to know where that erroneous quote from Alan Isaac
comes from, because if it's in Python's docs, it can be fixed.


Alex

[Gabriel Genellina]

Re: comparison with None

En Fri, 20 Apr 2007 11:40:00 -0300, Alex Martelli <aleax@mac.come scribió:

I'm still interested to know where that erroneous quote from Alan Isaac
comes from, because if it's in Python's docs, it can be fixed.

It was a partial quote, that's why it appeared to be wrong:

Library reference, 3.3 Comparisons

"Objects of different types, except different numeric types and different
string types, never compare equal; such objects are ordered consistently
but arbitrarily."

Reference Manual, 5.9 Comparisons

"The objects need not have the same type. If both are numbers, they are
converted to a common type. Otherwise, objects of different types always
compare unequal, and are ordered consistently but arbitrarily."

(Apart from the latter not menctioning string types too, looks good to me).

--
Gabriel Genellina

[Alex Martelli]

Re: comparison with None

Gabriel Genellina <gagsl-py2@yahoo.com.a rwrote:

En Fri, 20 Apr 2007 11:40:00 -0300, Alex Martelli <aleax@mac.come scribió:
>

I'm still interested to know where that erroneous quote from Alan Isaac
comes from, because if it's in Python's docs, it can be fixed.

>
It was a partial quote, that's why it appeared to be wrong:
>
Library reference, 3.3 Comparisons
>
"Objects of different types, except different numeric types and different
string types, never compare equal; such objects are ordered consistently
but arbitrarily."
>
Reference Manual, 5.9 Comparisons
>
"The objects need not have the same type. If both are numbers, they are
converted to a common type. Otherwise, objects of different types always
compare unequal, and are ordered consistently but arbitrarily."
>
(Apart from the latter not menctioning string types too, looks good to me).

Right. However, it might be worth underscoring that this applies to
_built-in_ types, and user-defined types are free to implement different
comparison semantics, although that should be done with care and good
taste; for example, one might have a collection type defining __eq__ to
mean "the same set of items as the other [iterable] operand in any
order", though that might cause weird behavior such as a==b but b!=a
(unfortunately there's no __req__, and __coerce__ is not involved in
comparisons either).

Still, not a major concern -- numbers and strings _do_ exhaust a vast
majority of the use cases for object of different types comparing equal.


Alex

[Gabriel Genellina]

Re: comparison with None

En Fri, 20 Apr 2007 23:48:02 -0300, Alex Martelli <aleax@mac.come scribió:

Gabriel Genellina <gagsl-py2@yahoo.com.a rwrote:
>

>Reference Manual, 5.9 Comparisons
>>
>"The objects need not have the same type. If both are numbers, they are
>converted to a common type. Otherwise, objects of different types always
>compare unequal, and are ordered consistently but arbitrarily."
>>
>(Apart from the latter not menctioning string types too, looks good to
>me).

>
Right. However, it might be worth underscoring that this applies to
_built-in_ types, and user-defined types are free to implement different
comparison semantics, although that should be done with care and good
taste; for example, one might have a collection type defining __eq__ to
mean "the same set of items as the other [iterable] operand in any
order", though that might cause weird behavior such as a==b but b!=a
(unfortunately there's no __req__, and __coerce__ is not involved in
comparisons either).

BTW, I think that the relationship between __eq__ and __hash__ (a==b =>
hash(a)==hash(b ), when hashable) should be more clearly stated too. I
almost got insane some time ago because of a faulty Rational numbers
implementation where hash(1/2)!=hash(2/4) (so dictionaries didn't work at
all).

--
Gabriel Genellina