builtin functions for and and or?

Roose b at b.b
Sun Feb 13 18:37:40 EST 2005


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.


<bearophileHUGS at lycos.com> wrote in message
news:1108335152.338013.45530 at z14g2000cwz.googlegroups.com...
> 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
>





More information about the Python-list mailing list