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

Josiah Carlson jcarlson at uci.edu
Sun Jan 4 19:29:22 EST 2004

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

Um, then why don't those people just write their own 'All'? It's not like they all need to be using the same definition of 'All', so why put it in Python?

Just because something is simple in idea and implementation, doesn't mean that it shouldn't be included with Python. The entire itertools module is filled with very useful functions that are simple in idea and implementation.

The introduction of All into Python would offer users the opportunity to use an always-compatible implementation of All, without the arbitrariness of argument placement during comparisons:

class AllType(object): ... def cmp(self, other): ... if isinstance(other, self.class): ... return 0 ... return 1 ... def repr(self): ... return 'All' ... class AllType2(object): ... def cmp(self, other): ... if isinstance(other, self.class): ... return 0 ... return 1 ... def repr(self): ... return 'All2' ... All = AllType() All2 = AllType2() All > All2 1 All2 > All 1

The "Motivation" section of PEP 326 does not answer this question. Although it claims "hundreds of algorithms", it demonstrates only one: finding the minimum of a sequence.

I should have probably made it more explicit. The most visible change when using All, in cases where a logical infinity was needed, is the removal of some "or (cur is None)" blobs. The next most visible change is the increase in understandability of some algorithms who require an infinity initialization.

The example shows three versions of finding a minimum of a sequence, to show that it's easier with 'All'. But that's a straw man argument: the easiest way to get the desired behavior is just to use 'min(seq)' and not write any new functions at all!

So, essentially, the "Motivation" section might as well not be in the PEP, because it provides no actual motivation at all. You need to find a better algorithm to cover.

I offered the finding the minimum code in order to offer an easily understood algorithm that is simplified by All's introduction. If you would like, I'll put together some code that solves various graph algorithm problems, use 'All', and are simplified because of it. I did not post any in the PEP because I believed that the implications of All were straightforward.

And don't bother using "find the pair x,y from a sequence of pairs where 'x' is the lowest item" as a substitute, because again the answer is 'min(seq)'. And even if you say, "yes but we don't want 'y' to be compared", there's always:

That is quite unfriendly and insulting. Call me an idiot next time, it'll be straighter to the point.

As Raymond Hettinger points out, Alex Martelli has a suggestion to allow the "key" keyword to min and max that could do everything required with with itemgetter. Or even:

def m(a,b): if a[0] < b[0]: return a return b reduce(m, seq)

"All" isn't about how many different ways there are to find the minimum of a sequence. "All" is about having a useful and consistant constant.

Thank you for your input,

More information about the Python-Dev mailing list