[Python-Dev] Re: PEP 326: A Case for All (original) (raw)

Josiah Carlson jcarlson at uci.edu
Sun Jan 4 15:00:37 EST 2004


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.



More information about the Python-Dev mailing list