======================================
Pythonic way to sum n-th list element?
======================================

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

Guy Middleton::

    >>> my_list = [[1, 2, 3], [40, 50, 60], [9, 8, 7]]
    >>> import functools as ft
    >>> ft.reduce(lambda a, b: a+b, [sub[1] for sub in my_list])
    60

LR::

    >>> ft.reduce(lambda a, b: a + b[1], my_list, 0)
    60

Fernando Perez::

    >>> import numpy as np
    >>> my_array = np.array(my_list)
    >>> np.sum(my_array[:, 1])
    60

Skip Montanaro::

    >>> import operator
    >>> ft.reduce(operator.add, [sub[1] for sub in my_list], 0)
    60
    >>> ft.reduce(operator.add, [sub[1] for sub in []])
    Traceback (most recent call last):
      ...
    TypeError: reduce() of empty sequence with no initial value
    >>> ft.reduce(operator.add, [sub[1] for sub in []], 0)
    0


Evan Simpson::

    >>> total = 0
    >>> for sub in my_list:
    ...     total += sub[1]
    >>> total
    60

Alex Martelli (``sum`` was added in Python 2.3, released July 9, 2003)::

    >>> sum([sub[1] for sub in my_list])
    60

After generator expressions (added in Python 2.4, November 30, 2004)::

    >>> sum(sub[1] for sub in my_list)
    60

If you want the sum of a list of items, you should write it in a way 
that looks like "the sum of a list of items", not in a way that looks 
like "loop over these items, maintain another variable t, perform a 
sequence of additions".  Why do we have high level languages if not to 
express our intentions at a higher level and let the language worry 
about what low-level operations are needed to implement it?

David Eppstein

Alex Martelli

https://mail.python.org/pipermail/python-list/2003-April/186311.html

"The sum" is so frequently needed that I wouldn't mind at all if
Python singled it out as a built-in.  But "reduce(operator.add, ..."
just isn't a great way to express it, in my opinion (and yet as an
old APL'er, and FP-liker, I _should_ like it -- but I don't).

https://mail.python.org/pipermail/python-list/2003-April/225323.html

Four years later, having coded a lot of Python, taught it widely,
written a lot about it, and so on, I've changed my mind: I now
think that reduce is more trouble than it's worth and Python
would be better off without it, if it was being designed from
scratch today -- it would not substantially reduce (:-) Python's 
power and WOULD substantially ease the teaching/&c task.  That's
not a strong-enough argument to REMOVE a builtin, of course, and
thus that's definitely NOT what I'm arguing for.  But I do suggest
avoiding reduce in most cases -- that's all.