[Python-Dev] Re: PEP 326: A Case for All

[Josiah Carlson]

Because All has generated as much disagreement as Some did initially,
All is definitely a poor name.

None being smaller than all other values was an arbitrary decision, and
may not be the case in the future.  Relying on it is probably not a good
idea - especially considering that most people do not know that it could
be used in this way. (Also noted by multiple people)

If None should not be relied upon, but the existance of a top and bottom
value limit make sense (a few people believe that it does), then really
we need two values.  Terry Reedy suggested making those objects
attributes of the cmp builtin.  This has the notable side-benefit of not
polluting the builtins namespace (YAY!).

Terry also suggested that the attributes be cmp.hi and cmp.lo, which
seem to be obvious attribute names for what they are.  String
representations for them are certainly up for debate, ObjHi/ObjLo,
NoneHi/NoneLo, Highest/Lowest, Infinity/NegativeInfinity were offered.
My only concern is that eval(repr(cmp.hi)) == cmp.hi and
eval(repr(cmp.lo)) == cmp.lo be true, but I am leaning toward
Highest/Lowest or hi/lo.


The names Infinity and NegativeInfinity seem to suggest numbers. 
Numbers can have math done on them.  Certainly there are a certain set
of behaviors that make sense, but then there are others that don't (like
Infinity - Infinity).  Whatever the top and bottom value limit end up
being called, whether or not they should allow math to be done on them
is probably up for debate.

Independant implementations of the top/bottom idea suffer from
the ordering of operands to a comparison function making a difference in
the result.  This may be a problem when an algorithm is written with one
top value in mind, yet another comes in and could gum up the works.


I've got another draft of my PEP that addresses the above comments and
concerns, and provides examples.  I'm going to sleep on it before
submitting the changes.

 - Josiah