type conversions for comparison operators

[Russ]

I recently discovered a bug in one of my programs that surprised me
because I thought Python's dynamic type checking would have
caught it.

Suppose I have a function that returns an integer, such as

def numItems: return len(self.items)

Now I want to do a test like this:

if object.numItems() > 2: <do something>

But suppose I mistakenly leave off the parentheses:

if object.numItems > 2: <do something>

I would have thought that Python would choke on this, but it
doesn't. Apparently, Python converts the operands to a common
type, but that seems risky to me. Is there a good reason for allowing
a function to be compared to an integer? Thanks.

 

[Alex Martelli]

I recently discovered a bug in one of my programs that surprised me
because I thought Python's dynamic type checking would have
caught it.

Suppose I have a function that returns an integer, such as

def numItems: return len(self.items)

Syntax errors (you need parentheses before the colon).

Now I want to do a test like this:

if object.numItems() > 2: <do something>

Attribute error (unless you've set that numItems "function" to be a
_method_ of the class of "object" AND added a "self" argument).

But suppose I mistakenly leave off the parentheses:

if object.numItems > 2: <do something>

I would have thought that Python would choke on this, but it
doesn't. Apparently, Python converts the operands to a common
type, but that seems risky to me. Is there a good reason for allowing
a function to be compared to an integer? Thanks.

It lets you sort a heterogeneous list which may include objects of many
types (and no "conversion to a common type" is involved, btw).

However, Guido's decided that Python 3.0 will not allow heterogeneous
order-comparisons any more (they can't be removed in 2.* without
breaking backwards compatibility -- 3.0 is allowed to break backwards
compatibility, but 2.* isn't).


Alex