Erik Demaine writes:
I propose (not for the first time) that similarly concatenating an unknown number of iterables or dicts should be possible via comprehensions:
``` (*it for it in its) # tuple with the concatenation of iterables in 'its' [*it for it in its] # list with the concatenation of iterables in 'its' {*it for it in its} # set with the union of iterables in 'its' {**d for d in dicts} # dict with the combination of dicts in 'dicts' ```
I don't have a problem with this, although that's moot if Guido doesn't.
There are other ways to do this, of course:
``` [x for it in its for x in it] itertools.chain(*its) sum(it for it in its, []) functools.reduce(operator.concat, its, []) ```
The last three are more or less obscure, and the sum version looks potentially very inefficient. Nested comprehensions are quite awkward because of the way both the occurances of 'x' and the occurances of 'it' are separated (and have to be). Despite the redundancy the suggestion seems plausible. There was a thread during the summer (sorry, no reference, it's bedtime) about something like container[*it] which uncovered some subtleties about implementing unpacking notation. I don't recall the details, except that it had to do with the fact that in indexing the indicies are passed as a tuple (even though there are no stdlib types that take multiple indicies). I think that means that it's not relevant to your proposal, but you might want to check, especially for tuple comprehensions like (*it for it in its).
2. Maybe `list1.append(a, b)` should be equivalent to `list1.extend([a, b])`?
[*it for it in its] has much greater appeal than multiargument .append, which looks much like .extend, and .extend already exists. I think equivalencing *it and .extend(it) makes much more sense. Steve