Why is None <= 0

[Gregor Horvath]

Hi,
True

Why?
Is there a logical reason?

Gregor

 

[Gary Herron]

Hi,

True

Why?
Is there a logical reason?

Gregor

In early Python, the decision was made that the comparison of *any* two
objects was legal and would return a consistent result. So objects of
different types will compare according to an ordering on their types (an
implementation dependent, unspecified, but consistent ordering), and
objects of the same type will be compared according to rules that make
sense for that type.

Other implementations have the right to compare an integer and None
differently, but on a specific implementation, the result will not change.

Python 3 will raise an exception on such comparisons.

Gary Herron

 

[Martin v. Löwis]

True

Why?
Is there a logical reason?

None is smaller than anything. The choice of
making it so is arbitrary, however, Python 2.x
tries to impose a total order on all objects (with varying
success), therefore, it is necessary to take arbitrary
choices.

(FWIW, in 2.x, x>=4?, it's None < numbers < anything else;
numbers are ordered by value, everything else is ordered
by type name, then by address, unless comparison functions
are implemented).

Regards,
Martin

 

[D'Arcy J.M. Cain]

True

Why?

Why not?

Is there a logical reason?

Everything in Python can compare to everything else. It is up to the
programmer to make sure that they are comparing reasonable things.

 

[Paul McNett]

True

More accurately:

True

Why?
Is there a logical reason?

None is "less than" everything except for itself:
True

In my humble opinion, I think that comparisons involving None should
return None, but I trust that the designers came up with this for very
good reasons. As far as I know I've never been bitten by it.

Paul

 

[Gregor Horvath]

Why not?

Because, from http://www.python.org/dev/peps/pep-0020/ :

Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.

Greg

 

[D'Arcy J.M. Cain]

In my humble opinion, I think that comparisons involving None should
return None...

Like relational databases.

 

[Christian Heimes]

In my humble opinion, I think that comparisons involving None should

return None, but I trust that the designers came up with this for very
good reasons. As far as I know I've never been bitten by it.

It's fixed in Python 3.x. Python 3.x refuses to compare objects unless
one of both objects has explicit support for both types:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < NoneType()

 

[Christian Heimes]

In my humble opinion, I think that comparisons involving None should

return None, but I trust that the designers came up with this for very
good reasons. As far as I know I've never been bitten by it.

It's fixed in Python 3.x. Python 3.x refuses to compare objects unless
one of both objects has explicit support for both types:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < NoneType()

 

[John Nagle]

Because, from http://www.python.org/dev/peps/pep-0020/ :

Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.

Greg

Good point.

The problem is the typical one; Python did not originally
have a Boolean type, and the retrofit resulted in weird semantics.
C has the same issue.

John Nagle

 

[blaine]

Quite apart from Jon pointing out that this isn't true for all cases when
copmparing against None, the other half also isn't true:


True

That happens at least in Python 2.5.2 on win32. Yet another reason to avoid
old-style classes.

Sorry - but what are new style classes?

 

[Aaron Watters]

According to Tim Peters, this is not true.

See http://bugs.python.org/issue1673405

This is unfortunate. I would advocate
something like ordering "incomparable objects"
by the name of their type or something
similar.

When building indexing structures it can be
very nice to be able to construct a list of
heterogeneous tuples and sort them without getting
an exception. Implementing this using L.sort(cmp) where
cmp is implemented in Python can result in
a significant speed penalty.

What's up with Tim Peters anyway? I haven't
seen much from him for a while.
-- Aaron Watters

===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=quote+tim+peters

 

[Terry Reedy]

|What's up with Tim Peters anyway? I haven't seen much from him for a
while.

I miss him too ;-)
He occasionally responds to tracker or pydev math issues where his unique
knowledge and experience is really needed. (As recently as last Jan).
That is all I know.
tjr