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

[Josiah Carlson]

> PEP 326 reads:
> > Users of Python have had the constant None, which represents a lack of
> > value, for quite some time (possibly from the beginning, this is
> > unknown to the author at the current time).  The author believes that
> > ``All`` should be introduced in order to represent a functionally
> > infinite value, with similar behavior corresponding to None.

[Gerrit Holl]
> I think the described behavious of None is one of the rarest uses of
> None. Actually, I didn't even know of the existence of this behaviour.
> I think None is mainly used to show the absence of *anything*: when a
> function does not return a value, it return None, when some variable
> does not have a value yet, it may be set to None, when a HTTP connection
> is not opened yet, it's socket is None, etc.

As previously offered by Tim Peters:
http://mail.python.org/pipermail/python-dev/2003-December/041374.html
The behavior of None being smaller than anything else was a concious
decision.  The use of All doesn't change the behavior of None.  How
people end up using All in their algorithms is up to them.

Does the Python language restrict the usage of None?  Of course not. 
Just as a function can return None (as a signal to the caller), a
function can now return All as a signal to the caller.

Further uses of All will be left as an exercise to whomever wants to use
it.

> > Introducing an ``All`` built-in that works as described does not take
> > much effort.  A sample Python implementation is included.
> 
> I don't think it is used very often. ``All`` is not a very
> straightforward name as well. The implementation is created very
> quickly: it can be done much simpler than you did, although it won't be
> called All then:
> 
> class Infinity(object):
>     def __cmp__(self, other):
>         return 1

The problem with your ``Infinity`` implementation is that it compares
greater than itself and doesn't follow the standard python object
convention of: a = obj;b = eval(repr(obj));a == b

>>> class Infinity(object):
...     def __cmp__(self, other):
...         return 1
...
>>> I = Infinity()
>>> I == I
0
>>> I is I
1
>>> I
<__main__.Infinity object at 0x007A5720>

The implementation that I offer in the PEP fixes the problem with your
``Infinity`` implementation.

> This is usable everywhere you describe. Because ``All`` is not a very
> straightforward name, I think the namespace cluttering is worse than the
> advantages. To convince me, I think you'll need to come up with a better
> name. It isn't ``All`` really, because that makes sence only with
> container types, it isn't ``Infinity`` because that makes sense only
> with numbers (strings?), so this is the biggest problem of your
> proposal.

All is a resonably lengthed name for the concept of 'bigger than
anything'.  This was independantly offered by two developers on the
python-dev mailing list:
Tim Peters:
http://mail.python.org/pipermail/python-dev/2003-December/041337.html
David LeBlanc
http://mail.python.org/pipermail/python-dev/2003-December/041386.html

It also has a similar naming semantic of None.  What is the opposite of
None (conceptually)?  All of course.


 - Josiah