[Python-Dev] Adding any() and all()

[François Pinard]

[Guido van Rossum]

> But I realized (1) any() and all() read much better in their natural
> context (an if statement), and there's no confusion there;

I do not think builtins should read good in some statement contexts and
bad in the others, or designed to be legible in only a few contexts.
This would be a waste.  In other contexts dans `if' or `while',
`any(...)' might be read as "pick one of", in which case a True/False
result might be surprising. `allTrue' (or such) is clearer in all
contexts, even if not as nice in some of them.  For `any(...)' to be
clear in all contexts, it should return one of its arguments.  That
would surely do the proper thing in `if' or `while' context.

We've read various arguments about this idea.  Some (pro or con)
arguments are only valid outside `if' and `while' context, other (pro
and con) arguments are only valid within `if' and `while' context.  If
we are going to dismiss contexts outside `if' and `while', we should not
retain arguments which only apply outside those contexts.

This is my only complain.  The overall idea and principle are good,
especially if they succeed in cleaning out `reduce' and the others.
However, if for compatibility reasons, `reduce' stays, than we are
merely adding other ways, without sparing any, and this means yet
another tiny bloat in Python, that might be better avoided.

> What worries me a bit about doing a PEP for this simple proposal is
> that it might accidentally have the wrong outcome:

Isn't that true of any PEP?  I thought going through a PEP for changes,
and additions just as well, was not far from being a principle.
Depending on opinions, the outcome is right or wrong.

The principle of PEPs is not necessarily a good one in practice, as some
PEPs are forever incomplete or unupdated, miss their role, and then sum
up to having nearly been an annoyance.  Good if PEPs may be avoided! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca