On Mon, Dec 19, 2011 at 9:28 AM, Nathan Rice email@example.com wrote:
-- Performing a series of operations using comprehensions or map tends to be highly verbose in an uninformative way. Compare the current method with what would be possible using "typed" collections:
L2 = [X(e) for e in L1] L3 = [Y(e) for e in L2] vs L2 = X(L1) # assuming X has been updated to work in both vector/scalar L3 = Y(L2) # context...
This use case is why map() remains a builtin, even in Python 3:
L2 = map(X, L1) L3 = map(Y, L2)
Short, but explicit (no under-the-hood guessing about whether or not something should be treated as a scalar or vector value - in the general case, this distinction isn't as clear as you might think, just look at strings).
L2 = [Z(Y(X(e))) for e in L1] vs L2 = Z(Y(X(L1)))
def XYZ(arg): """Look, I can document what this means!""" return Z(Y(X(arg)))
L2 = map(XYZ, L1)
L2 = [e.X().Y().Z() for e in L1] vs L2 = L1.X().Y().Z() # assuming vectorized versions of member methods #are folded into the collection via the mixin.
def XYZ_methods(arg): """I can also document what *this* means""" return arg.X().Y().Z()
L2 = map(XYZ_methods, L1)
-- Because collections are type agnostic, it is not possible to place methods on them that are type specific. This leads to a lot of cases where python forces you to read inside out or a the syntax gets very disjoint in general. A good example of this is:
"\n".join(l.capitalize() for l in my_string.split("\n"))
which could reduce to something far more readable, such as:
Another bad example, since that's just a really verbose way of writing my_string.capitalize().
Short answer: what advantage does your proposal really offer over simply extracting the repetitive operation out to a use case specific function, and making effective use of the existing vectorisation utilities (i.e. map() and itertools)?