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

[Josiah Carlson]

> >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,
 - Josiah