Interesting list Validity (True/False)

[mensanator at aol.com]

On May 13, 8:57?am, Carsten Haese <cars... at uniqsys.com> wrote:
> On Sat, 2007-05-12 at 18:43 -0700, mensana... at aol.com wrote:
> > > 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'>
>
> All right, so what you meant was "Assuming that arg is a list, 'if
> arg==True' will always fail because lists never compare equal to any
> boolean."
>
> > 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>
>
> > [snip examples of "surprising" equality tests...]
>
> The statement I made is simply the meaning of "if arg==True" by
> definition, so I don't see how it can be nonsensical.

Because you didn't allow for exceptions, which are
prominently pointed out in the Python docs.

>
> The problem is that you consider equality tests in Python to be
> nonsensical because they don't fit with your opinion of what equality
> should mean.

No, it has nothing to do with what it means. 1, [1], (1,)
and mpz(1) are all different types and all mathmatically
the same. Yet 1 and mpz(1) compare equal but (1,) and
[1] do not. The later fails due to type mis-match, the
former does not despite type mis-match due to the fact
they are the same mathematically.

I'm not saying the situation is wrong, what I'm saying
is that somone who doesn't understand why arg==True
is failing should be told ALL the rules, not just the easy
ones.

>
> Regards,
>
> --
> Carsten Haesehttp://informixdb.sourceforge.net