|
Re: The fate of reduce() in Python 3000
|
Posted: Mar 11, 2005 8:29 AM
|
|
Here's my take on the key issues brought up (this is a copy of an email I sent to python-dev, where an independent discussion of the same issues is happening):
Alternative names anytrue(), alltrue(): before I posted to my blog I played with these names (actually anyTrue(), allTrue(), anyFalse(), allFalse()). But I realized (1) any() and all() read much better in their natural context (an if statement), and there's no confusion there; (2) anyFalse() and allFalse() are redundant, so there's no need to distinguish between anyTrue() and anyFalse(). (To the person who wondered why we default to True: because 'if' tests for True, duh. :-)
Whether to always return True and False or the first faling / passing element? I played with that too before blogging, and realized that the end case (if the sequence is empty or if all elements fail the test) can never be made to work satisfactory: picking None feels weird if the argument is an iterable of bools, and picking False feels weird if the argument is an iterable of non-bool objects.
Whether to use each() and some() instead of all() and any(), to preserve variable namespace: each() in particular (and some() to some extent) emphasizes the individual element, while all() emphasizes the whole set. As long as we accept that the return value should not return one of the arguments elements, I prefer emphasizing the group. The namespace argument doesn't weigh much in my mind; there's no backwards incompatibility, and there are plenty of builtins that are routinely reused as variables (e.g. str, file, id, type) without apparently affecting readability. Context helps a lot!
Whether to segregate these into a separate module: they are really a very small amount of syntactic sugat, and I expect that in most cases, instead of importing that module (which totally makes me lose my context while editing) I would probably just write the extra line that it takes to get the same effect with an explicit for loop and if statement.
What worries me a bit about doing a PEP for this simple proposal is that it might accidentally have the wrong outcome: a compromise that can carry a majority rather than the "right" solution because nobody could "sell" it. Yet, if people really feel strongly that there are more issues that need to be discussed, and they think it's worth their time, let someone stand up now to own the PEP and guide the discussion. But personally, I think it's more efficient if Raymond just checks in his code now. :-)
BTW I definitely expect having to defend removing map/filter/reduce/lambda with a PEP; that's much more controversial because it's *removing* something and hence by definition breaking code. The PEP, in addition to making a really strong case for each of the removals, will have to deal with a deprecation period, possibly moving the functions to a "functional programming" module, etc.
PS in the blog responses, a problem with sum() was pointed out -- unless you use the second argument, it will only work for numbers. Now that string concatenation is apparently O(N) rather than O(N**2) (is that right, Raymond?) maybe this could be revised.
|
|