default object comparison considered harmful?

[castironpi]

On May 16, 8:18 am, castironpi <castiro... at gmail.com> wrote:
> On May 16, 7:23 am, Bruno Desthuilliers <bruno.
>
>
>
>
>
> 42.desthuilli... at websiteburo.invalid> wrote:
> > Kay Schluehr a écrit :
>
> > > On 16 Mai, 10:03, "A.T.Hofkamp" <h... at se-162.se.wtb.tue.nl> wrote:
> > >> 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?