[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
