Re: Interesting list Validity (True/False)

On Sat, 12 May 2007 18:43:54 -0700, mensanator@xxxxxxx wrote:

On May 12, 8:10?pm, Carsten Haese <cars...@xxxxxxxxxxx> wrote:
On Sat, 2007-05-12 at 17:55 -0700, mensana...@xxxxxxx wrote:
On May 12, 12:56?pm, Carsten Haese <cars...@xxxxxxxxxxx> wrote:
On Fri, 2007-05-11 at 14:26 -0700, mensana...@xxxxxxx wrote:
if arg==True:

tests the type property (whether a list is a boolean).

That sounds nonsensical and incorrect. Please explain what you mean.

<quote>
Sec 2.2.3:
Objects of different types, except different numeric types and
different string types, never compare equal;
</quote>

I should point out that only applies to built-in types, not custom classes.


That doesn't explain what you mean. How does "if arg==True" test whether
"a list is a boolean"?

type(sys.argv)
<type 'list'>
type(True)
<type 'bool'>


That still doesn't make sense. However, using my incredible psychic
ability to read between the lines, I think what Mensanator is trying (but
failing) to say is that "if arg==True" first tests whether arg is of type
bool, and if it is not, it knows they can't be equal. That's not actually
correct. We can check this:

import dis
def test(arg):
.... return arg == True
....
dis.dis(test)
2 0 LOAD_FAST 0 (arg)
3 LOAD_GLOBAL 0 (True)
6 COMPARE_OP 2 (==)
9 RETURN_VALUE


As you can see, there is no explicit type test. (There may or may not be
an _implicit_ type test, buried deep in the Python implementation of the
COMPARE_OP operation, but that is neither here nor there.)

Also, since bool is a subclass of int, we can do this:

1.0+0j == True
True





Actually, it's this statement that's non-sensical.

<quote>
"if arg==True" tests whether the object known as arg is equal to the
object known as True.
</quote>

Not at all, it makes perfect sense. X == Y always tests whether the
argument X is equal to the object Y regardless of what X and Y are.


None of these four examples are "equal" to any other.

That's actually wrong, as you show further down.


a = 1
b = (1,)
c = [1]
d = gmpy.mpz(1)

type(a)
<type 'int'>
type(b)
<type 'tuple'>
type(c)
<type 'list'>
type(d)
<type 'mpz'>
a==b
False
b==c
False
a==d
True

See, a and d are equal.


And yet a==d returns True. So why doesn't b==c
also return True, they both have a 1 at index position 0?

Why should they return true just because the contents are the same? A bag
of shoes is not the same as a box of shoes, even if they are the same
shoes. Since both lists and tuples are containers, neither are strings or
numeric types, so the earlier rule applies: they are different types, so
they can't be equal.

gmpy.mpz(1) on the other hand, is both a numeric type and a custom class.
It is free to define equal any way that makes sense, and it treats itself
as a numeric type and therefore says that it is equal to 1, just like 1.0
and 1+0j are equal to 1.


--
Steven.

.

Relevant Pages

  • Re: Interesting list Validity (True/False)
    ... numeric types and different string types, ... the equivalency of numeric types and do the type conversion, ... the print statement isn't so smart. ...
    (comp.lang.python)
  • Re: Interesting list Validity (True/False)
    ... except different numeric types and ... different string types, never compare equal; ... "a list is a boolean"? ... they both have a 1 at index position 0? ...
    (comp.lang.python)
  • Re: Interesting list Validity (True/False)
    ... That sounds nonsensical and incorrect. ... except different numeric types and ... different string types, never compare equal; ...
    (comp.lang.python)
  • Re: comparison with None
    ... 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." ... Gabriel Genellina ...
    (comp.lang.python)
  • Re: Interesting list Validity (True/False)
    ... different string types, never compare equal; ... Why should the int 1 return True when compared to mpz? ... of shoes is not the same as a box of shoes, even if they are the same ... numeric types, so the earlier rule applies: ...
    (comp.lang.python)