[Alex Martelli] > On Sunday 20 April 2003 02:01 am, Brett Cannon wrote: > ... > > So I have no fundamental issue with the proposed function, but I don't > > find a huge need for it personally; I always do the looping solution > > (jaded against the functional stuff from school =). > > Looping is what I'm doing these days, but while fastest it's not terribly > convenient. And it took me a while to learn to avoid reduce for that... > True, but "explicit is better than implicit". But don't take this to mean that I don't think that your proposed function is not good; I do think it has merit. <snip> > Agreed on collocation -- itertools or math would be inappropriate, and > builtins best, but since there are already so many builtins many are > understandably reacting badly to the idea of adding anything there. > So, if builtins are to be considered untouchable, I'd rather have sum > in operator (where it does sort of fit, I think) than do without it. > Fair enough. Either that or a new module. <snip> > So, let's see if I can express this more clearly...: > > It's not a question of tyranny of anybody -- it's a question of the degree > of abstraction required to find "reduce(operator.add, L)" the ``one > obvious way'' to sum numbers being quite a bit above everyday thought > habits. If we say that "the one obvious way" is a loop it becomes hard > to justify why the one obvious way to find a maximum is max(L) rather > than a perfectly similar loop -- after all "sum these numbers" and "find > the largest one of these numbers" are tasks with perfectly comparable > frequency of applicability in everyday programming tasks and perceived > complexity. (My implementation for sum is a small copy-past-edit job > on that of max/min, removing the special-case the latter have when > called with >1 argument and adding one to delegate to ''.join for the > specific purpose of summing instances of PyBaseString_Type -- the > structure is really very similar). > That's better. =) Comes off less as "let's add this to make newcomers happy" and more as "this will simplify good code". The latter is a always a good thing. I have an idea to respond to the whole "everyone will want prod() next" idea, but I will put that in another email to try to keep this thread coherent. -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4