# Argparse: Multiple arguments with the same destination left-to-right order guarantee

**URL:** <https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685>\
**Category:** Python Help\
**Tags:** documentation, argparse\
**Created:** [January 13, 2026, 7:40am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685 "2026-01-13T07:40:15Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![pdgendt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pdgendt/32/33644_2.png) [@pdgendt](https://discuss.python.org/u/pdgendt)\
**Post date:** [January 13, 2026, 7:40am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/1 "2026-01-13T07:40:15Z")

</div>

Reading the `argparse` docs, I didn’t find a formal guarantee that arguments are parsed from left-to-right, or “in order”, which is especially useful for a “last argument wins” approach when using the same destination.

For example:

```python
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', action='store_const', const='foo', dest='val')
>>> parser.add_argument('--bar', action='store_const', const='bar', dest='val')
>>> parser.parse_args(['--bar', '--foo'])
Namespace(val='foo')
>>> parser.parse_args(['--bar', '--foo', '--bar'])
Namespace(val='bar')

```

This works intuitively, but isn’t documented. Is it simply missing a note in the documentation, or isn’t it safe to assume?

---

<div class="post-metadata">

**Author:** ![c-rob](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/c-rob/32/17261_2.png) [@c-rob](https://discuss.python.org/u/c-rob)\
**Post date:** [January 13, 2026, 9:55am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/2 "2026-01-13T09:55:26Z")

</div>

I would just do a test with a short program. I even have a program dir called “test” just for tests like this. Like this: `python app.py --arg1:100 --arg1:200`

A gotcha in Python 3.14: (long) arguments with a single dash are processed differently now. I think that started in 3.13. So I’m converting all my long arguments to two dashes --.

---

<div class="post-metadata">

**Author:** ![pdgendt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pdgendt/32/33644_2.png) [@pdgendt](https://discuss.python.org/u/pdgendt)\
**Post date:** [January 13, 2026, 10:12am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/3 "2026-01-13T10:12:39Z")

</div>

I have tested it, and it works as expected, that’s not the issue.

For context, I suggested in a PR review for an open source project ([runners: openocd: add BIN file flash support by sylvioalves · Pull Request #101888 · zephyrproject-rtos/zephyr · GitHub](https://github.com/zephyrproject-rtos/zephyr/pull/101888#issuecomment-3742555081)) to use this mechanism, but it was commented that this isn’t officially documented, and therefor we shouldn’t rely on it.

---

<div class="post-metadata">

**Author:** ![c-rob](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/c-rob/32/17261_2.png) [@c-rob](https://discuss.python.org/u/c-rob)\
**Post date:** [January 13, 2026, 10:24am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/4 "2026-01-13T10:24:26Z")

</div>

I see, you want a formal guarantee. I suggest you find the Github page and create a Feature Request for the docs.

---

<div class="post-metadata">

**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\
**Post date:** [January 13, 2026, 11:07am UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/5 "2026-01-13T11:07:11Z")

</div>

Although when present, `args` is typed as `Sequence[str]` in the [typeshed](https://github.com/python/typeshed/blob/ce2b37da4568a08502edcd245d07ee5184967f3b/stdlib/argparse.pyi#L203) (i.e. not `Iterable`), calling it with an iterator of strings, results in parsing them ‘L’ → ‘R’, so `.parse_args` just iterates over `args`.

```python
>>> parser.parse_args((s for s in ['--bar', '--foo', '--bar']))
Namespace(val='bar')

```

If this is intentional (as it would appear from the source code [`arg_strings_iter = iter(arg_strings)`](https://github.com/python/cpython/blob/510ab7d6e1284dd2ac453b780fa19b5627bca0e1/Lib/argparse.py#L2153) plus an `args.extend` call) then it should be straightforward to request a change of type signature on Typeshed.

Personally I think reversing them first (R → L) is quite surprising. It should be documented clearly, if this feature is ever added. But I noticed:

> POSIX recommends these conventions for command line arguments  
> …
> 
> - Options may be supplied in any order, or appear multiple times. The interpretation is left up to the particular application program.  
> [Argument Syntax (The GNU C Library)](https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html)

---

<div class="post-metadata">

**Author:** ![marc-h38](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/marc-h38/32/11355_2.png) [@marc-h38](https://discuss.python.org/u/marc-h38)\
**Post date:** [January 13, 2026, 4:18pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/6 "2026-01-13T16:18:50Z")

</div>

Thank you @JamesParrott. Short of being documented, it’s great to see this is at least intentional in the code.

> [@JamesParrott](#):
>
> Personally I think reversing them first (R → L) is quite surprising.

I was more concerned about a top-level iteration based on something else, like the `add_argument("-x",...)`s for instance. Hopefully that does not make sense and will never happen.

---

<div class="post-metadata">

**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\
**Post date:** [January 13, 2026, 4:30pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/7 "2026-01-13T16:30:53Z")

</div>

> [@c-rob](#):
>
> A gotcha in Python 3.14: arguments with a single dash are processed differently now.

What exactly is the difference?

---

<div class="post-metadata">

**Author:** ![c-rob](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/c-rob/32/17261_2.png) [@c-rob](https://discuss.python.org/u/c-rob)\
**Post date:** [January 13, 2026, 4:49pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/8 "2026-01-13T16:49:36Z")

</div>

I fixed my statement to say “Long arguments with one dash are processed differently.” An argument like “-version” won’t get passed to the program itself, it gets passed to Python I think. I had to fix all my programs to use two dashes with long arguments, so “-version” became “–version”.

---

<div class="post-metadata">

**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\
**Post date:** [January 13, 2026, 7:07pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/9 "2026-01-13T19:07:26Z")

</div>

Could you show an example?

---

<div class="post-metadata">

**Author:** ![marc-h38](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/marc-h38/32/11355_2.png) [@marc-h38](https://discuss.python.org/u/marc-h38)\
**Post date:** [January 13, 2026, 7:10pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/10 "2026-01-13T19:10:20Z")

</div>

Just for the record, this was already discussed in the more specific `BooleanOptionalAction`context: [`argparse.BooleanOptionalAction` does not yield mutually exclusive options · Issue #119375 · python/cpython · GitHub](https://github.com/python/cpython/issues/119375)

Like it or not, it is not unusual for build systems to have many “layers”/”overlays” and then have more specific layers overriding less specific layers with a latter `--feature` overriding an earlier `--no-feature` or vice-versa.

Don’t get me wrong: this is very far from “standard practice”. The devil is in the details! But it’s not unusual. And when conflicting options are not rejected, I don’t remember any example where an earlier one wins.

> <https://stackoverflow.com/questions/52874345/is-gcc-flags-repetition-and-ordering-important/52891069#52891069>

---

<div class="post-metadata">

**Author:** ![pdgendt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pdgendt/32/33644_2.png) [@pdgendt](https://discuss.python.org/u/pdgendt)\
**Post date:** [January 14, 2026, 3:17pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/11 "2026-01-14T15:17:06Z")

</div>

So I’m not entirely sure if this is an actual solution to my question, or if this implies additional actions, such as updating the documentation?

---

<div class="post-metadata">

**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\
**Post date:** [January 14, 2026, 7:02pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/12 "2026-01-14T19:02:07Z")

</div>

It’s strong informal reassurance, not a formal guarantee.

If the order is ever reversed, all the Python CLI apps out there accepting multiple arguments will break. I see no appetite whatsoever to deal with a back lash that big, simply to save the few people that need multiple args processing the other way round to normal iteration, from adding in `reversed` to their code.

---

<div class="post-metadata">

**Author:** ![tjreedy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tjreedy/32/137_2.png) [@tjreedy](https://discuss.python.org/u/tjreedy)\
**Post date:** [January 14, 2026, 10:12pm UTC](https://discuss.python.org/t/argparse-multiple-arguments-with-the-same-destination-left-to-right-order-guarantee/105685/13 "2026-01-14T22:12:45Z")

</div>

The [parse\_args doc](https://docs.python.org/3/library/argparse.html#the-parse-args-method) says " args - List of strings to parse. …" The proposal is to add something like ‘, in normal order’ to the end of the sentence. The reason is that parsing each arg has a side effect and that the net effect of parsing all args may depend on the order of parsing.

I suggest opening a feature request on the tracker. Reference this discussion. The consensus here, I believe, is that the behavior should never change, so that the order should be guaranteed. The main issue is whether it already is or not, which is to say, whether the addition would be redundant or not. Making the request minimal, such as 3 words, makes the bar for adding it relatively low. Let the few coredevs involved with argparse decide.