[Python-Dev] Re: PEP 326 now online (the big reply)

[Josiah Carlson]

> > 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

Ah hah!

> > > 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, I very much like your suggestions.  Your "SUBSTITUTE SUGGESTION"
is better than my original proposal.  I'm off to modify the PEP to
address these suggested changes, as well as various clarifications that
are necessary.

Mind if I put you down as a co-author?

 - Josiah