Yeah, as we can see there are a million ways to do it. But none of them are as desirable as just having a library function to do the same thing. I'd argue that since there are so many different ways, we should just collapse them into one: any() and all(). That is more in keeping with the python philosophy I suppose -- having one canonical way to do things. Otherwise you could see any of these several ways of doing it in any program, and each time you have to make sure it's doing what you think. Each of them requies more examination than is justified for such a trivial operation. And this definitely hurts the readability of the program.
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In Python there are so many ways to do things... > This looks like another one, I haven't tested it: > > not False in imap(pred, iterable) > > As usual tests are required to measure the faster one. > I agree with Roose, there are are some "primitive" operations (like > this, and flatten, partition, mass removal of keys from a dictionary, > and few others) that can be added to the language (but I'm still not > capabable of doing it myself, and Python is free, so it's not right to > ask people to work for free for us). > > Bear hugs, > Bearophile > -- http://mail.python.org/mailman/listinfo/python-list
