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

Josiah Carlson jcarlson at uci.edu
Mon Jan 5 00:33:17 EST 2004

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

More information about the Python-Dev mailing list