On Sat, 12 May 2007 18:43:54 -0700, [EMAIL PROTECTED] wrote:
> On May 12, 8:10?pm, Carsten Haese <[EMAIL PROTECTED]> wrote:
>> On Sat, 2007-05-12 at 17:55 -0700, [EMAIL PROTECTED] wrote:
>> > On May 12, 12:56?pm, Carsten Haese <[EMAIL PROTECTED]> wrote:
>> > > On Fri, 2007-05-11 at 14:26 -0700, [EMAIL PROTECTED] 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.
--
http://mail.python.org/mailman/listinfo/python-list
