|
| 1 | +====================================== |
| 2 | +Pythonic way to sum n-th list element? |
| 3 | +====================================== |
| 4 | + |
| 5 | +Examples inspired by Guy Middleton's question on Python-list, Fri Apr 18 22:21:08 CEST 2003. Message: https://mail.python.org/pipermail/python-list/2003-April/218568.html |
| 6 | + |
| 7 | +Guy Middleton:: |
| 8 | + |
| 9 | + >>> my_list = [[1, 2, 3], [40, 50, 60], [9, 8, 7]] |
| 10 | + >>> import functools as ft |
| 11 | + >>> ft.reduce(lambda a, b: a+b, [sub[1] for sub in my_list]) |
| 12 | + 60 |
| 13 | + |
| 14 | +LR:: |
| 15 | + |
| 16 | + >>> ft.reduce(lambda a, b: a + b[1], my_list, 0) |
| 17 | + 60 |
| 18 | + |
| 19 | +Fernando Perez:: |
| 20 | + |
| 21 | + >>> import numpy as np |
| 22 | + >>> my_array = np.array(my_list) |
| 23 | + >>> np.sum(my_array[:, 1]) |
| 24 | + 60 |
| 25 | + |
| 26 | +Skip Montanaro:: |
| 27 | + |
| 28 | + >>> import operator |
| 29 | + >>> ft.reduce(operator.add, [sub[1] for sub in my_list], 0) |
| 30 | + 60 |
| 31 | + >>> ft.reduce(operator.add, [sub[1] for sub in []]) |
| 32 | + Traceback (most recent call last): |
| 33 | + ... |
| 34 | + TypeError: reduce() of empty sequence with no initial value |
| 35 | + >>> ft.reduce(operator.add, [sub[1] for sub in []], 0) |
| 36 | + 0 |
| 37 | + |
| 38 | + |
| 39 | +Evan Simpson:: |
| 40 | + |
| 41 | + >>> total = 0 |
| 42 | + >>> for sub in my_list: |
| 43 | + ... total += sub[1] |
| 44 | + >>> total |
| 45 | + 60 |
| 46 | + |
| 47 | +Alex Martelli (``sum`` was added in Python 2.3, released July 9, 2003):: |
| 48 | + |
| 49 | + >>> sum([sub[1] for sub in my_list]) |
| 50 | + 60 |
| 51 | + |
| 52 | +After generator expressions (added in Python 2.4, November 30, 2004):: |
| 53 | + |
| 54 | + >>> sum(sub[1] for sub in my_list) |
| 55 | + 60 |
| 56 | + |
| 57 | +If you want the sum of a list of items, you should write it in a way |
| 58 | +that looks like "the sum of a list of items", not in a way that looks |
| 59 | +like "loop over these items, maintain another variable t, perform a |
| 60 | +sequence of additions". Why do we have high level languages if not to |
| 61 | +express our intentions at a higher level and let the language worry |
| 62 | +about what low-level operations are needed to implement it? |
| 63 | + |
| 64 | +David Eppstein |
| 65 | + |
| 66 | +Alex Martelli |
| 67 | + |
| 68 | +https://mail.python.org/pipermail/python-list/2003-April/186311.html |
| 69 | + |
| 70 | +"The sum" is so frequently needed that I wouldn't mind at all if |
| 71 | +Python singled it out as a built-in. But "reduce(operator.add, ..." |
| 72 | +just isn't a great way to express it, in my opinion (and yet as an |
| 73 | +old APL'er, and FP-liker, I _should_ like it -- but I don't). |
| 74 | + |
| 75 | +https://mail.python.org/pipermail/python-list/2003-April/225323.html |
| 76 | + |
| 77 | +Four years later, having coded a lot of Python, taught it widely, |
| 78 | +written a lot about it, and so on, I've changed my mind: I now |
| 79 | +think that reduce is more trouble than it's worth and Python |
| 80 | +would be better off without it, if it was being designed from |
| 81 | +scratch today -- it would not substantially reduce (:-) Python's |
| 82 | +power and WOULD substantially ease the teaching/&c task. That's |
| 83 | +not a strong-enough argument to REMOVE a builtin, of course, and |
| 84 | +thus that's definitely NOT what I'm arguing for. But I do suggest |
| 85 | +avoiding reduce in most cases -- that's all. |
0 commit comments