# Syntactic sugar to encourage use of named arguments

**URL:** <https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217>\
**Category:** Ideas\
**Created:** [October 14, 2023, 5:38pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217 "2023-10-14T17:38:31Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![joshuabambrick](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/joshuabambrick/32/15299_2.png) [@joshuabambrick](https://discuss.python.org/u/joshuabambrick)\
**Post date:** [October 14, 2023, 5:38pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/1 "2023-10-14T17:38:31Z")

</div>

**Issue**

Named arguments confer many benefits by promoting _explicit is better than implicit_, thus increasing readability and minimising the risk of inadvertent transposition. However, the syntax can become needlessly repetitive and verbose.

Consider the following call:

```auto
my_function(
  my_first_variable=my_first_variable,
  my_second_variable=my_second_variable,
  my_third_variable=my_third_variable,
)

```

The verbosity and redundancy discourages use of named arguments (and therefore, their benefits) and reduces readability by increasing noise. I have personally encountered this many times.

**Proposition**

I would like to propose a simple syntactic sugar in the case that the name of the variable provided as the argument value is the same as the name of the argument itself.

```auto
my_function(=my_first_variable, =my_second_variable, =my_third_variable)

```

**Benefits**

- Encourages use of named variables, thereby increasing readability (_explicit is better than implicit_) and reducing bugs from argument transposition
- Reduces verbosity (_readability counts_)
- Encourages authors to use the same variable name when calling a function as the argument (increases consistency of variable names used, thereby increasing _readability_)
- Reminiscent of python’s long-standing `*args` and `**kwargs` syntax (established pythonic style)
- Reminiscent of python’s existing f-string debug `f'{var=}'` syntax (established pythonic style) and with a very similar function
- This should be relatively easy to implement as it is simple syntactic sugar (_if the implementation is easy to explain, it may be a good idea_)
- Backwards compatibility: this change is fully backwards compatible since the proposed syntax would raise a syntax error in current python versions

---

<div class="post-metadata">

**Author:** ![ehomrich](https://avatars.discourse-cdn.com/v4/letter/e/f0a364/32.png) [@ehomrich](https://discuss.python.org/u/ehomrich)\
**Post date:** [October 14, 2023, 5:51pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/2 "2023-10-14T17:51:36Z")

</div>

There are some discussions about this idea, but there was no consensus/conclusion:

> [@Shorthand notation of dict literal and function call](https://discuss.python.org/t/shorthand-notation-of-dict-literal-and-function-call/5697):
>
> It is sometimes tedious to write a dictionary in Python. For example, def register\_user(first, last, addr1, addr2): d = {'first': first, 'last': last, 'addr1': addr1, 'addr2': addr2,} register(d) The dict literal above contains a lot of duplicated words and quotation marks. JavaScript has shorthand notation of property names. d = {first, last, addr1, addr2} In Python, {first, last, addr1, addr2} yields set object. So, how about adding a new notation to Pyt…

> [@Allow identifiers as keyword arguments at function call site (extension of PEP 3102?)](https://discuss.python.org/t/allow-identifiers-as-keyword-arguments-at-function-call-site-extension-of-pep-3102/31677):
>
> It is common to see keyword arguments passed values from identifiers (typically local variables) with the same name as the argument. Here’s an [example](https://pytorch.org/docs/stable/_modules/torch/optim/sgd.html#SGD) from the pytorch library: func(params, d\_p\_list, momentum\_buffer\_list, weight\_decay=weight\_decay, momentum=momentum, lr=lr, dampening=dampening, nesterov=nesterov, has\_sparse\_grad=has\_sparse\_grad, maximize=maximize) My proposal is to allow these keyword arguments to be passed as e.g. weight\_decay inst…

---

<div class="post-metadata">

**Author:** ![UltimateLobster](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ultimatelobster/32/9727_2.png) [@UltimateLobster](https://discuss.python.org/u/UltimateLobster)\
**Post date:** [October 15, 2023, 7:18am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/3 "2023-10-15T07:18:51Z")

</div>

I think that having the equal sign at the end of the variable `func(a=)` may ease the implementation and be more intuitive because you already have a similar syntax for f strings:  
`f"{x=}"`

---

<div class="post-metadata">

**Author:** ![tmk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tmk/32/10935_2.png) [@tmk](https://discuss.python.org/u/tmk)\
**Post date:** [October 15, 2023, 10:46am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/4 "2023-10-15T10:46:03Z")

</div>

[Ruby has this feature](https://www.ruby-lang.org/en/news/2021/12/25/ruby-3-1-0-released/): `foo(x:, y:)` is syntax sugar for `foo(x: x, y: y)`.

I think I maybe prefer the equal sign at the beginning, but it’s more consistent with the Python 3.8 format string syntax if it’s at the end.

Here is more prior discussion:

[https://mail.python.org/archives/list/python-ideas@python.org/thread/SIMIOC7OW6QKLJOTHJJVNNBDSXDE2SGV/](https://mail.python.org/archives/list/python-ideas@python.org/thread/SIMIOC7OW6QKLJOTHJJVNNBDSXDE2SGV/)

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [October 15, 2023, 11:21am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/5 "2023-10-15T11:21:58Z")

</div>

I don’t know what the SC will think of this proposal, and I don’t have time to do a lot of mentoring in this area, but if a few folks here will come together and submit a PEP (following the process from PEP 1) and you need a sponsor you can put my name in. I personally prefer the syntax `foo(x=, y=)`.

---

<div class="post-metadata">

**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\
**Post date:** [October 15, 2023, 11:30am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/6 "2023-10-15T11:30:23Z")

</div>

I can help out as needed. Who wants to champion the proposal and write up the PEP?

> **[PEP 1 – PEP Purpose and Guidelines | peps.python.org](https://peps.python.org/pep-0001/#submitting-a-pep)**
>
> Python Enhancement Proposals (PEPs)

---

<div class="post-metadata">

**Author:** ![joshuabambrick](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/joshuabambrick/32/15299_2.png) [@joshuabambrick](https://discuss.python.org/u/joshuabambrick)\
**Post date:** [October 15, 2023, 11:41am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/7 "2023-10-15T11:41:51Z")

</div>

I’d be very happy to write up the PEP

---

<div class="post-metadata">

**Author:** ![joshuabambrick](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/joshuabambrick/32/15299_2.png) [@joshuabambrick](https://discuss.python.org/u/joshuabambrick)\
**Post date:** [October 15, 2023, 3:31pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/8 "2023-10-15T15:31:13Z")

</div>

I’ll get started on this now. Thank you Guido and Chris.

---

<div class="post-metadata">

**Author:** ![hels15](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hels15/32/14265_2.png) [@hels15](https://discuss.python.org/u/hels15)\
**Post date:** [October 15, 2023, 6:59pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/9 "2023-10-15T18:59:33Z")

</div>

I would be interested in helping as well.

---

<div class="post-metadata">

**Author:** ![roo.oliv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/roo.oliv/32/15311_2.png) [@roo.oliv](https://discuss.python.org/u/roo.oliv)\
**Post date:** [October 15, 2023, 7:41pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/10 "2023-10-15T19:41:51Z")

</div>

Great to see this feature being discussed again after so many years, signals that its value is sound. I would be happy to contribute.

---

<div class="post-metadata">

**Author:** ![joshuabambrick](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/joshuabambrick/32/15299_2.png) [@joshuabambrick](https://discuss.python.org/u/joshuabambrick)\
**Post date:** [October 15, 2023, 8:35pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/11 "2023-10-15T20:35:55Z")

</div>

Fantastic, thanks so much both! I’m going to research this a little more and think about how a draft will look but will certainly follow up

---

<div class="post-metadata">

**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\
**Post date:** [October 15, 2023, 9:06pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/12 "2023-10-15T21:06:55Z")

</div>

This might help: [PEP 12 – Sample reStructuredText PEP Template | peps.python.org](https://peps.python.org/pep-0012/)

---

<div class="post-metadata">

**Author:** ![NeilGirdhar](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/neilgirdhar/32/5776_2.png) [@NeilGirdhar](https://discuss.python.org/u/NeilGirdhar)\
**Post date:** [October 16, 2023, 1:53am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/13 "2023-10-16T01:53:45Z")

</div>

> [@roo.oliv](#):
>
> Great to see this feature being discussed again after so many years, signals that its value is sound. I would be happy to contribute.

I think the arguments presented this time around are the most motivating (at least to me). In particular, I like this one: “Encourages authors to use the same variable name when calling a function as the argument”. That’s something I will intentionally fix if argument names drift apart. In my opinion, it is beneficial to have syntax that induces coders to do this.

I don’t think this argument was suggested the last couple times this was proposed.

---

<div class="post-metadata">

**Author:** ![csm10495](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/csm10495/32/9731_2.png) [@csm10495](https://discuss.python.org/u/csm10495)\
**Post date:** [October 16, 2023, 4:15am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/14 "2023-10-16T04:15:08Z")

</div>

Can the PEP have a recommendation for static analysis tools (like mypy) catch if this is used but the corresponding variable of the same name doesn’t exist?

---

<div class="post-metadata">

**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\
**Post date:** [October 16, 2023, 6:29am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/15 "2023-10-16T06:29:30Z")

</div>

> [@csm10495](#):
>
> Can the PEP have a recommendation for static analysis tools (like mypy)

Yes, definitely…

> [@csm10495](#):
>
> catch if this is used but the corresponding variable of the same name doesn’t exist?

… though I suspect that this is nothing more than a plain vanilla NameError. Am I understanding you correctly, and you mean code like this?

```auto
def spam():
    x = 1234 # no y
    func(x=x, y=y)
    func(x=, y=) # or func(=x, =y) if that's the chosen syntax

```

If so, it should be no different from the longhand line above it, or any other attempt to reference a variable that doesn’t exist. Obviously static analysis tools will have to be taught about the new syntax, but that’s the case for all syntax.

Or were there other recommendations you had in mind?

---

<div class="post-metadata">

**Author:** ![csm10495](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/csm10495/32/9731_2.png) [@csm10495](https://discuss.python.org/u/csm10495)\
**Post date:** [October 16, 2023, 8:54pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/16 "2023-10-16T20:54:06Z")

</div>

Yep that’s the main thing I had in mind. I figure if nested, it wouldn’t be caught at import time, but static analysis could warn on it.

---

<div class="post-metadata">

**Author:** ![Rosuav](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rosuav/32/3429_2.png) [@Rosuav](https://discuss.python.org/u/Rosuav)\
**Post date:** [October 16, 2023, 9:09pm UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/17 "2023-10-16T21:09:26Z")

</div>

> [@csm10495](#):
>
> I figure if nested, it wouldn’t be caught at import time, but static analysis could warn on it.

Yeah, there’s definitely value in catching this sort of thing statically. I’ve no idea which checkers report on this (I gave MyPy a quick whirl and it didn’t report it, but that’s with default settings so maybe that can be turned on), but regardless, it should be able to be reported on regardless of this particular piece of syntax.

---

<div class="post-metadata">

**Author:** ![TeamSpen210](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/teamspen210/32/1004_2.png) [@TeamSpen210](https://discuss.python.org/u/TeamSpen210)\
**Post date:** [October 17, 2023, 1:39am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/18 "2023-10-17T01:39:21Z")

</div>

Mypy can do that check, but it’s [disabled by default](https://mypy.readthedocs.io/en/stable/error_code_list2.html#warn-about-variables-that-are-defined-only-in-some-execution-paths-possibly-undefined). Probably because it’s rather tricky to catch all the situations correctly, so it’s likely that you’ll get false positives.

---

<div class="post-metadata">

**Author:** ![csm10495](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/csm10495/32/9731_2.png) [@csm10495](https://discuss.python.org/u/csm10495)\
**Post date:** [October 17, 2023, 5:31am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/19 "2023-10-17T05:31:52Z")

</div>

I think I prefer `param=` over the equals sign on the other side. My editor (vscode) already would be happy to autocomplete this since it lets me tab complete `var=`

Like in a day at work, I already saw multiple times that I would use this functionality.

So cool!

---

<div class="post-metadata">

**Author:** ![TomRitchford](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tomritchford/32/6123_2.png) [@TomRitchford](https://discuss.python.org/u/TomRitchford)\
**Post date:** [October 19, 2023, 7:41am UTC](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217/20 "2023-10-19T07:41:05Z")

</div>

I would use it all the time, it would debulk a lot of code that I read, but Python already has too much stuff.

On the balance, I am weakly in favour of this, with the `key=` syntax.

[Next page](https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217.md?page=2)