default object comparison considered harmful?

[A.T.Hofkamp]

Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.
Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)
Sincerely,
Albert

[Bruno Desthuilliers]

A.T.Hofkamp a écrit :

Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.
Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Other than implementing a custom __cmp__ function ? Not AFAIK. FWIW, you
don't necessarily need to fiddle with inheritance - you can also
monkeypatch your classes (nb : for new-style objects, you cannot
monkeypatch __magic__ methods on a per-object basis).

Also, IIRC, this behaviour has changed in Python 3.

[Peter Otten]

A.T.Hofkamp wrote:

Yesterday we found the cause of a bug that has caused problems for a long
time. It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.
Is there a way to disable this behavior in Python (other than deriving a
new 'object-like' class that doesn't do comparisons?)

As Bruno says, this will change in 3.0:

# 3.0

>>class A: pass

....

>>min(1.0, A())

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() < float()

For 2.5 and above you can provide a key function as a workaround:

# 2.5

>>class A(object): pass

....

>>min(1, A(), key=float)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: float() argument must be a string or a number

Peter

[Kay Schluehr]

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:

Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.

Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Sincerely,
Albert

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

[Bruno Desthuilliers]

Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:

>Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.

Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

print 1.0 + A()

[castironpi]

On May 16, 7:23*am, Bruno Desthuilliers <bruno.
[e-mail]:

Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:

Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
* * pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numericalin
nature.

The cause of this behavior seems to be the compare operation of the object
class.

Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

* * print 1.0 + A()- Hide quoted text -

- Show quoted text -

I question the real-world examples of coercion, casting, and
upcasting. C insists that defining by operator, which may or may not
relate to system, is the only legal move. I doubt operator+ is well-
defined on non-ideal structures. Rationals are not floats, but system
got checked. Define concurrency.

[castironpi]

On May 16, 8:18*am, castironpi <[e-mail]:

On May 16, 7:23*am, Bruno Desthuilliers <bruno.

[e-mail]:

Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:
>Hello all,

>Yesterday we found the cause of a bug that has caused problems for a long time.
>It appeared to be the following:

>class A(object):
>* * pass

>print min(1.0, A())

>which is accepted by Python even though the A() object is not numerical in
>nature.

>The cause of this behavior seems to be the compare operation of the object
>class.

>Is there a way to disable this behavior in Python (other than deriving a new
>'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

* * print 1.0 + A()- Hide quoted text -

- Show quoted text -

I question the real-world examples of coercion, casting, and
upcasting. *C insists that defining by operator, which may or may not
relate to system, is the only legal move. *I doubt operator+ is well-
defined on non-ideal structures. *Rationals are not floats, but system
got checked. *Define concurrency.- Hide quoted text -

- Show quoted text -

The computer will have to learn knowledge at a distributed real-time
rate.

[castironpi]

On May 16, 8:18*am, castironpi <[e-mail]:

On May 16, 7:23*am, Bruno Desthuilliers <bruno.

[e-mail]:

Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:
>Hello all,

>Yesterday we found the cause of a bug that has caused problems for a long time.
>It appeared to be the following:

>class A(object):
>* * pass

>print min(1.0, A())

>which is accepted by Python even though the A() object is not numerical in
>nature.

>The cause of this behavior seems to be the compare operation of the object
>class.

>Is there a way to disable this behavior in Python (other than deriving a new
>'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

* * print 1.0 + A()- Hide quoted text -

- Show quoted text -

I question the real-world examples of coercion, casting, and
upcasting. *C insists that defining by operator, which may or may not
relate to system, is the only legal move. *I doubt operator+ is well-
defined on non-ideal structures. *Rationals are not floats, but system
got checked. *Define concurrency.- Hide quoted text -

- Show quoted text -

I would be bouncing localcy and remoticy. What word's on the bar?

[castironpi]

On May 16, 8:35*am, castironpi <[e-mail]:

On May 16, 8:18*am, castironpi <[e-mail]:

On May 16, 7:23*am, Bruno Desthuilliers <bruno.

[e-mail]:

Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:
Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
* * pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of theobject
class.

Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

* * print 1.0 + A()- Hide quoted text -

- Show quoted text -

I question the real-world examples of coercion, casting, and
upcasting. *C insists that defining by operator, which may or may not
relate to system, is the only legal move. *I doubt operator+ is well-
defined on non-ideal structures. *Rationals are not floats, but system
got checked. *Define concurrency.- Hide quoted text -

- Show quoted text -

I would be bouncing localcy and remoticy. *What word's on the bar?- Hidequoted text -

- Show quoted text -

Can you suffixize words? I have corner, cornercy, lunacy, emphatic,
emphasize, a value of Y, orderings, say, remoticy, & cross. Come do
graphics. Anybody speak?

For verbs, I have: say, speak, see, talk, and stack. Pretty
harmless. Still here?

[castironpi]

On May 16, 9:10*am, castironpi <[e-mail]:

On May 16, 8:35*am, castironpi <[e-mail]:

On May 16, 8:18*am, castironpi <[e-mail]:

On May 16, 7:23*am, Bruno Desthuilliers <bruno.

[e-mail]:
Kay Schluehr a écrit :

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:
>Hello all,

>Yesterday we found the cause of a bug that has caused problems for a long time.
>It appeared to be the following:

>class A(object):
>* * pass

>print min(1.0, A())

>which is accepted by Python even though the A() object is not numerical in
>nature.

>The cause of this behavior seems to be the compare operation of the object
>class.

>Is there a way to disable this behavior in Python (other than deriving a new
>'object-like' class that doesn't do comparisons?)

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

This is not necessarily a static vs dynamic typing problem. The
following code will raise a TypeError for very good reasons:

* * print 1.0 + A()- Hide quoted text -

- Show quoted text -

I question the real-world examples of coercion, casting, and
upcasting. *C insists that defining by operator, which may or may not
relate to system, is the only legal move. *I doubt operator+ is well-
defined on non-ideal structures. *Rationals are not floats, but system
got checked. *Define concurrency.- Hide quoted text -

- Show quoted text -

I would be bouncing localcy and remoticy. *What word's on the bar?- Hide quoted text -

- Show quoted text -

Can you suffixize words? *I have corner, cornercy, lunacy, emphatic,
emphasize, a value of Y, orderings, say, remoticy, & cross. *Come do
graphics. *Anybody speak?

For verbs, I have: say, speak, see, talk, and stack. *Pretty
harmless. *Still here?- Hide quoted text -

- Show quoted text -

That's stay tuned I'M BARTENDER. Is that a space BAR ZOOP.

[Terry Reedy]

| On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:
| Yesterday we found the cause of a bug that has caused problems for a
long time.
| It appeared to be the following:
| >
| class A(object):
| pass
| >
| print min(1.0, A())
| >
| which is accepted by Python even though the A() object is not numerical
in
| nature.
| >
| The cause of this behavior seems to be the compare operation of the
object
| class.
| >
| Is there a way to disable this behavior in Python (other than deriving
a new
| 'object-like' class that doesn't do comparisons?)

Use Python 3! That is one of many improvements.

[A.T.Hofkamp]

On 2008-05-16, Kay Schluehr <ka**********@gmx.netwrote:

On 16 Mai, 10:03, "A.T.Hofkamp" <[e-mail]:

>Hello all,

Yesterday we found the cause of a bug that has caused problems for a long time.
It appeared to be the following:

class A(object):
pass

print min(1.0, A())

which is accepted by Python even though the A() object is not numerical in
nature.

The cause of this behavior seems to be the compare operation of the object
class.

Is there a way to disable this behavior in Python (other than deriving a new
'object-like' class that doesn't do comparisons?)

Sincerely,
Albert

Are you sure you don't want to use a statically typed language that
captures all type errors just by inspecting your source code?

yes.

The problem here is that it isn't caught at all, neither at 'compile' time nor
at run-time. That means that the Python language considers this proper code.

Whether you make that decision by inspecting source code or at run-time is
irrelevant here.
Unfortunaly, we have to maintain Python 2.3 compability.
As a solution, I have created a new BaseObject class as follows:

class BaseObject(object):
"""
Generic base class without default compare and hashing functions.
"""
def __cmp__(self, other):
""" Disable default compare method """
raise NotImplementedError

def __hash__(self):
""" Disable default hashing method """
raise NotImplementedError("Implement me in class '%s'"
% self.__class__.__name__)
Sincerely,
Albert