# Should \`list.extend\` and \`dict.update\` be variadic?

**URL:** <https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672>\
**Category:** Ideas\
**Created:** [July 30, 2025, 1:41pm UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672 "2025-07-30T13:41:07Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![adqm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/adqm/32/28615_2.png) [@adqm](https://discuss.python.org/u/adqm)\
**Post date:** [July 30, 2025, 1:41pm UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/1 "2025-07-30T13:41:07Z")

</div>

This thought came up in [the discussion thread for PEP 798](https://discuss.python.org/t/99435) and I thought it might be worth some more discussion.

We can currently add elements from a whole bunch of iterables to a set by calling `set.update` with multiple arguments passed in:

```python
>>> L = [[1,2,3], [], [4,5]]
>>> x = set()
>>> x.update(*L)
>>> x
{1, 2, 3, 4, 5}

```

However, `list.extend` and `dict.update` can’t be called in a similar way. For those, we would need a loop and multiple method calls to get the same result:

```python
>>> L = [[1,2,3], [], [4,5]]
>>> x = []
>>> for list_ in L:
... x.extend(list_)
...
>>> x
[1, 2, 3, 4, 5]

```

```python
>>> L = [{1: 2}, {}, {3: 4, 1: 10}, [(9, 10)]]
>>> x = {}
>>> for dict_ in L:
... x.update(dict_)
...
>>> x
{1: 10, 3: 4, 9: 10}

```

I think we should consider making `list.extend` and `dict.update` variadic as well, making them behave more like `set.update` and allowing code like the following:

```python
>>> L = [[1,2,3], [], [4,5]]
>>> x = []
>>> x.extend(*L)
>>> x
[1, 2, 3, 4, 5]

```

```python
>>> L = [{1: 2}, {}, {3: 4, 1: 10}, [(9, 10)]]
>>> x = {}
>>> x.update(*L)
>>> x
{1: 10, 3: 4, 9: 10}

```

I put together a quick [proof-of-concept implementation](https://github.com/adqm/cpython/tree/variadic_extend) of this idea, and an [Emscripten-based demo](https://hz.mit.edu/python_demos/variadic_extend/) in case anyone wants to play with this idea without needing to compile it yourself.

I’m curious what other people think.

---

<div class="post-metadata">

**Author:** ![effigies](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/effigies/32/35835_2.png) [@effigies](https://discuss.python.org/u/effigies)\
**Post date:** [July 30, 2025, 1:54pm UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/2 "2025-07-30T13:54:11Z")

</div>

They’re backwards compatible, and I can’t readily think of a way they would encourage subtly wrong code. I think this would be a nice improvement, as long as the semantics of `dict.update(d, a, b, c)` are the same as `d.update({ **a,** b, **c})` and `d.update(a); d.update(b); d.update(c)`.

---

<div class="post-metadata">

**Author:** ![dg-pb](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dg-pb/32/16248_2.png) [@dg-pb](https://discuss.python.org/u/dg-pb)\
**Post date:** [July 30, 2025, 2:08pm UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/3 "2025-07-30T14:08:14Z")

</div>

If this does not break backwards compatibility and there aren’t any other better ways to utilise this argument space, I am +1.

Also, if this is done, I think `Sequence` and `Mapping` would ideally adapt this as well.

---

<div class="post-metadata">

**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\
**Post date:** [July 30, 2025, 2:15pm UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/4 "2025-07-30T14:15:03Z")

</div>

> [@dg-pb](#):
>
> Also, if this is done, I think `Sequence` and `Mapping` would ideally adapt this as well.

This is not really possible ☹

There is no good way of evolving these interfaces.

---

<div class="post-metadata">

**Author:** ![adqm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/adqm/32/28615_2.png) [@adqm](https://discuss.python.org/u/adqm)\
**Post date:** [August 13, 2025, 5:11am UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/5 "2025-08-13T05:11:15Z")

</div>

> [@MegaIng](#):
>
> There is no good way of evolving these interfaces.

Forgive my ignorance, but could you elaborate? Is there more to this than just updating the `MutableSequence` and `MutableMapping` interfaces in `collections.abc`?

---

<div class="post-metadata">

**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\
**Post date:** [August 13, 2025, 5:16am UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/6 "2025-08-13T05:16:26Z")

</div>

> [@adqm](#):
>
> Is there more to this than just updating the `MutableSequence` and `MutableMapping` interfaces in `collections.abc`?

Yes. It also involves updating all existing implementations out in the wild to still be compatible with the new design, no matter if those implementations derive from the abc, are subclassing the corresponding typing Protocol or are implicitly implementing the Protocol.

If you don’t do this, code will no longer be able to properly interact and make assumptions about what it means to be a `MutableMapping`.

Obviously, this is not a feasible thing to do. Therefore there is no good way of evolving these interfaces.

---

<div class="post-metadata">

**Author:** ![adqm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/adqm/32/28615_2.png) [@adqm](https://discuss.python.org/u/adqm)\
**Post date:** [August 13, 2025, 5:43am UTC](https://discuss.python.org/t/should-list-extend-and-dict-update-be-variadic/100672/7 "2025-08-13T05:43:06Z")

</div>

Yep, this makes sense; the downstream effects would definitely be a big challenge 🫤. And changing `list.extend` and `dict.update` _without_ similarly changing `MutableSequence` and `MutableMapping` would be painful as well.

That said, I do feel it’s a bit of a shame if the relationship between the built-in types and these interfaces means that any proposed changes to any of the associated methods are complete non-starters, especially for things like this that are backward-compatible.
