2

I have a list of tuples, from which I am removing the ith element. Right now I'm doing this with:

map(lambda e: list(e)[:i] + list(e)[(i + 1):], data)

which converts the tuple to a list (twice!) and then slices out the element. The result means that I have lists instead of tuples- but this is perfectly fine. Is there a faster way of doing this, possibly by converting each tuple to a list in a separate map operation?

zcleghern
  • 827
  • 7
  • 21

2 Answers2

6

You don't need to convert to a list at all. Just slice the tuple; slicing doesn't mutate a tuple, it creates a new object:

map(lambda e: e[:i] + e[i:], data)

Not that the above slice operations are any use, because slicing to i and from i would create the exact same tuple. You want to add 1 to the start of the second slice if i should be omitted:

map(lambda e: e[:i] + e[i + 1:], data)

Demo:

>>> t = (41, 42, 45, 54, 81, 162)
>>> t[:3] + t[3:]  # same tuple again
(41, 42, 45, 54, 81, 162)
>>> t[:3] + t[4:]  # skip index 3
(41, 42, 45, 81, 162)

You may want to reconsider using tuples here; tuples are really more designed for heterogenous data structures; tuples have structure, lists have order. See What's the difference between lists and tuples?

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
3

No need to wrap this to a list, you can just:

map(lambda e: (*e[:i], *e[i+1:]), data)

But these approaches all will take O(m n) time with m the arity of the tuples and n the number of tuples.

The above will also process siceable iterables, so not per se tuples. Furthermore the result is always a tuple. For example for a range(..) object:

>>> i=3
>>> list(map(lambda e: (*e[:i], *e[i+1:]), [range(1,7)]))
[(1, 2, 3, 5, 6)]

This is not per se wanted behavior. One can also use e[:i] + e[i+1:], this will then raise an error for a range(..) object. For a list, it will return a list. There is not an "inherent" better approach: it depends on the use case.

Willem Van Onsem
  • 443,496
  • 30
  • 428
  • 555
  • 1
    This is not actually different from concatenation though. – Martijn Pieters Oct 19 '18 at 20:01
  • @MartijnPieters: these are not *functionally* equivalent. I prefer using iterable unpacking, since this will work with any slicable iterable, whereas for a list of lists, this will result in a list, for `range(..)` objects, this will construct a tuple as well, but indeed for tuples itself, there is no difference. So it gives more guarantees at the "output side", and takes more types at the "input side". – Willem Van Onsem Oct 19 '18 at 20:04
  • Fair enough, iterable unpacking does operate differently when `e` is *not* a tuple. It depends on the use-case if you actually want to support arbitrary iterators or if that should be an error. – Martijn Pieters Oct 19 '18 at 20:05