[Python-Dev] Re: PEP 326 now online

[Terry Reedy]

"Josiah Carlson" <jcarlson at uci.edu> wrote in message
> Give it a look: http://www.python.org/peps/pep-0326.html

OBJECTION

"All comparisons including None and another object results in None being
the smaller of the two."  is not exactly true.

>>> class lo:
...   def __cmp__(s,o): return -1
...
>>> ll=lo()
>>> ll < None
1

> > The name must be something else like Infinity or something more
> > suggestive of what it does.
>
> What does the name 'None' suggest about what it does?

What None is designed to do is to denote 'nothing' and the name 'None' does
that very well.  This is at least 99% of its current usage.  That it
compares to other objects at all is irrelevant to this main usage and is at
least partly an artifact of the former rule that all objects should be
comparable, even with arbitrary results.  If Python had started with
complex numbers and some non-comparabilities, None might just have well
been made incomparable to anything, as I think it maybe should be and might
be in 3.0.

The name 'None' suggests almost nothing about the incidental fact that it
usually compares low.  [Indeed I find no such guarantee in current LibRef
2.3.3 Comparisons (and 2.3.9.7 The Null Object) and it contradicts
"Implementation note: Objects of different types except numbers are ordered
by their type names".]  I consider this lack of suggestiveness to be a
negative feature.  Adding another object with a non-suggestive name would
only compound what is arguably a mistake.  (The mistake being to overload
None as both a null object and as half of a lo/hi comparison pair, which is
quite a different function.)


SUBSTITUTE SUGGESTION

I do believe that it would be useful (and arguably justifiable) to have a
built-in coordinated pair of hi/lo, top/bottom objects *separate* from
None.  To avoid adding builtin names, they could be bound to cmp as the
attributes cmp.hi and cmp.lo.  It would be almost obvious, and trivial to
remember, that these are objects that compare hi and lo respectively.  They
could be instances of object, NoneType, or maybe a new CompType.  Their
string representations could be ObjHi/ObjLo, NoneHi/NoneLo (if of type
object or NoneType), or maybe Highest and Lowest.

Since these two objects would function as identities for comparison, I
would make them the default start values for max and min reductions, so
that max() = max([]) = Highest and  min() = min([]) = Lowest, instead of
raising exceptions, just as sum([]) = 0.  This is, however, an optional
part of this suggestion.

I believe this alternative meets the goal of your PEP better and would
perhaps be more acceptible (but we'll hear about that ;-).  I would
certainly support it.


MOTIVATION

Add the following as an example of one of the "hundreds of algorithms that
begin by initializing some set of values to a logical (or numeric)
infinity" that is *not* covered by built in min and max.

"For example, in Dijkstra's shortest path problem on weighted edges, one
starts out by setting the distances of everything in the graph to
infinity, setting the starting point distance to zero, then
systematically pulling out the node with smallest distance, adding its
neighbors, etc.  Min and max are arbitrarily limiting, which is why they
aren't used."

Terry J. Reedy