# PEP 736: Shorthand syntax for keyword arguments at invocation **URL:** \ **Category:** PEPs\ **Created:** [January 17, 2024, 2:11pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432 "2024-01-17T14:11:03Z")\ **Posts on this page:** 20\ **Page:** 8
**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:** [February 4, 2024, 10:30pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/143 "2024-02-04T22:30:48Z")
> [@pf\_moore](#): > > And yet, a lot of the discussion here from supporters of the proposal seems to suggest that switching to use the new form is always the right thing to do. I’ve been supporting this proposal from the start, but have never said you should ALWAYS use it. Use it when it makes sense, like every other new feature. I’m personally against autoformatters in general, so I’ve stayed out of that wing of the discussion, so I suppose maybe my silence was taken as support for that view?? ---
**Author:** ![jagerber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jagerber/32/9412_2.png) [@jagerber](https://discuss.python.org/u/jagerber)\ **Post date:** [February 4, 2024, 11:03pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/144 "2024-02-04T23:03:17Z")
> [@pf\_moore](#): > > … a lot of the discussion here from supporters of the proposal seems to suggest that switching to use the new form is always the right thing to do. I haven’t seen people **in general** arguing along these lines with respect to PEP 736 as a language feature. I’m not sure if anyone has said anything along those lines? The conversation about linters/formatters is a different story. Obviously if linters/formatters adopt auto-conversion by default then that is forcing users of those tools into using the short hand syntax in all cases because, as you point out, a linter can’t look at the semantics of the code and determine, based on writers preference, whether a particular instance should be converted or not. I guess I don’t yet know if I would want my linter/formatter to flag or convert these transformations yet. I’d want to use the feature for a bit and see if I like it. I’m also suspicious that I would be in favor of using this feature in all cases where its applicable but haven’t really looked at code with an eye towards this to be sure. If my suspicions are right then I wouldn’t be upset by my linter/formatter automatically converting. In other words, I’m curious to try out the feature a bit and find cases where I would prefer NOT to use the shorthand syntax. But I 100% recognize that this whole paragraph is my personal opinion and others will validly have different opinions. For the short term my opinion is the safe route seems to be linters/formatters would support the shorthand notation or the long hand notation, but not convert one way or the other unless the user opts into that behavior. > [@pf\_moore](#): > > I repeat my request - _please_ try to emphasise in the PEP that the forms `f(x=x)` and `f(x=)` are different but equivalent forms, and it should be the programmer’s choice which is appropriate in any given situation. I want to look at the PEP language again but if it needs stronger warning against blindly applying the transformation from `f(x=x)` to `f(x=)` in all cases I’m not opposed to that at all. ---
**Author:** ![jagerber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jagerber/32/9412_2.png) [@jagerber](https://discuss.python.org/u/jagerber)\ **Post date:** [February 5, 2024, 3:15am UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/145 "2024-02-05T03:15:14Z")
The current recommendation in the PEP is > As with any other language feature, the programmer should exercise their own judgement about whether to use it in any given context. We do not recommend enforcing a rule to use the feature in all cases where it may be applicable. And Joshua extended above > As described above, we propose that a reasonable rule of thumb would be to use this in cases where a parameter and its argument have the same semantics in order to reduce unintentional desynchronisation without causing inappropriate coupling. Maybe more emphasis on this point could be included in the `how to teach this` section where examples could be given for when users might consider using this feature and when users might consider not using this feature. Do we have concrete examples of when not to use this feature in this thread already? I’ll take a glance through. * * * edit: Actually there are two things to warn against. It sounds like there are cases where one should avoid converting `f(x=x)` to `f(x=)`, but we should also warn against specifically renaming variables for the sole purpose of using this feature. In some cases that might be a fine thing to do. But in some cases it should likewise be avoided. ---
**Author:** ![jeff5](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jeff5/32/1518_2.png) [@jeff5](https://discuss.python.org/u/jeff5)\ **Post date:** [February 5, 2024, 8:43am UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/146 "2024-02-05T08:43:08Z")
> [@elis.byberi](#): > > > [@jeff5](#): > > > > `module.name = "Alice"` is questionable PEP 736 or no. > > It would be very useful for setting configuration variables. For example, you can read the configuration file and set the configuration variables in any module you want using just a function. You don’t need a `config` variable. What I mean here is that module-level configuration, set from one place then then affecting the results other callers get, is questionable design. If a module is a private singleton in an application, I think it is manageable. But if you hope for re-use, then it’s a bad idea, as different parts of the same application might want different configuration. I think this is what @boxed means by “universally seen as horribly bad”. Several libraries that started this way have introduced a context object class to avoid this problem and that’s the usual way to proceed in new code. I read your post as pointing out (by irony) that PEP 736 made this anti-pattern more attractive to the inexperienced programmer. ---
**Author:** ![boxed](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/boxed/32/5966_2.png) [@boxed](https://discuss.python.org/u/boxed)\ **Post date:** [February 5, 2024, 9:01am UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/147 "2024-02-05T09:01:24Z")
I am a strong supporter of this proposal, but I would never claim that it would be better if an autoformatter overrode the judgment of the programmer. ---
**Author:** ![elis.byberi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/elis.byberi/32/35937_2.png) [@elis.byberi](https://discuss.python.org/u/elis.byberi)\ **Post date:** [February 5, 2024, 4:42pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/148 "2024-02-05T16:42:17Z")
> [@jeff5](#): > > (by irony) I try to be very direct and clear. I have made my point, and I didn’t request a response or interpretations. * * * I believe that discussion threads are for discussing possible edge cases for the new ideas and how they should be addressed. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 4:45pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/149 "2024-02-05T16:45:45Z")
> [@Jelle](#): > > I am a maintainer of Black. I would want Black to enforce PEP 736 style where possible. > > That means I disagree with @pf_moore just above. If we don’t think that linters should recommend PEP 736 style, then I don’t see why we’d add the feature to the language. +1 to what Jelle said. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [February 5, 2024, 9:18pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/150 "2024-02-05T21:18:20Z")
> [@ambv](#): > > > [@Jelle](#): > > > > I am a maintainer of Black. I would want Black to enforce PEP 736 style where possible. > > > > That means I disagree with @pf_moore just above. If we don’t think that linters should recommend PEP 736 style, then I don’t see why we’d add the feature to the language. > > +1 to what Jelle said. The idea that linters should enforce every possible syntactical construct is weird. I wouldn’t want a linter to start enforcing the assignment operator everywhere possible, for example. But then, I have a deep dislike of Black so it’s no wonder that I disagree with its designers’ mindset as well. 🤷 ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 9:19pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/151 "2024-02-05T21:19:35Z")
> [@pitrou](#): > > every possible syntactical construct That’s obviously a strawman argument but you already knew that. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [February 5, 2024, 9:20pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/152 "2024-02-05T21:20:43Z")
Then please explain carefully why this would be true while not being true of other recently-added features: > If we don’t think that linters should recommend PEP 736 style, then I don’t see why we’d add the feature to the language. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 9:30pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/153 "2024-02-05T21:30:25Z")
The key sentence in PEP 736 is that the new syntax > will be interpreted exactly equivalently to the current verbose syntax. This implies the produced AST will be equivalent. The code isn’t different semantically at all, it’s just shorter, i.e. reads (and writes!) quicker. Therefore, there’s no danger in making this transformation. It produces consistent results across the board, inviting more use, which – in line with the PEP – has the effects of encouraging more consistent variable naming, encouraging use of keyword arguments, and reduces verbosity. Of course, this transformation can only be performed when the config file for the codebase specifies that it’s 3.13+, otherwise it would no longer run on older versions of Python. ---
**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\ **Post date:** [February 5, 2024, 10:05pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/154 "2024-02-05T22:05:19Z")
> [@ambv](#): > > Therefore, there’s no danger in making this transformation. Isn’t the issue being raise not that its a runtime change but that it is not always clear that the new syntax is as readable in some situations? ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 10:15pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/155 "2024-02-05T22:15:40Z")
Ultimately that’s for the SC to decide. If the PEP passes then I believe the message is that it’s clearly better to have it rather than not. We don’t usually disturb status quo for marginal wins. Due to the sheer decrease in character count, information density is lowered. I believe this will be a net positive. Is the equal sign too insignificant for visibility? I don’t think so. It’s already used as a postfix symbol in f-string expressions without issue. And it occupies just as much space as the asterisk that signifies variadic arguments. But again, it’s up to the SC. If this gets accepted, Black intends to embrace it. ---
**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:** [February 5, 2024, 10:16pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/156 "2024-02-05T22:16:06Z")
> [@ambv](#): > > Therefore, there’s no danger in making this transformation. It produces consistent results across the board, inviting more use, which – in line with the PEP – has the effects of encouraging more consistent variable naming, encouraging use of keyword arguments, and reduces verbosity. Does black also recommend transforming all instances of `f"x={x}"` to `f"{x=}"`? Those are also entirely equivalent, but express a slight difference in intent (if you rename the variable `x`, the second one will have the label follow the rename, the first one won’t). ---
**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:** [February 5, 2024, 10:26pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/157 "2024-02-05T22:26:10Z")
> [@ambv](#): > > The key sentence in PEP 736 is that the new syntax > > > will be interpreted exactly equivalently > > to the current verbose syntax. This implies the produced AST will be equivalent. The code isn’t different semantically at all, it’s just shorter, i.e. reads (and writes!) quicker. This has to be a none argument, otherwise black should remove all unnecessary whitespace and reduce all indentation to 1 space per level. Being shorter and quicker the read/write is not the measurement for what a linter should do. > [@ambv](#): > > Due to the sheer decrease in character count, information density is lowered. I believe this will be a net positive. That is not how density works. It is the same amount of information expressed in less characters, so the density is higher. But tbf, I have zero interested in black’s opinions anyway and this stance hasn’t improved my view of the project. I am still weakly in favor of this proposal, but if the result in PRs “improving” the code with this change because black/the SC said so (we are already getting PRs with nothing but “black said so”), then I am strongly against. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 10:37pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/158 "2024-02-05T22:37:32Z")
> [@Rosuav](#): > > Does black also recommend transforming all instances of `f"x={x}"` to `f"{x=}"`? Ironically the AST for the f-string case is not equivalent. `f"{x=}"` means `f"x={x!r}"`. Consequently, Black doesn’t touch it. In fact, currently it doesn’t touch string insides (besides reindenting docstrings and tidying escape sequences). > [@MegaIng](#): > > That is not how density works. I’m sorry, yes, I meant to say the opposite but I hope you got my meaning. > [@MegaIng](#): > > I have zero interested in black’s opinions anyway Thanks for letting us know! ---
**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:** [February 5, 2024, 10:40pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/159 "2024-02-05T22:40:02Z")
> [@ambv](#): > > I’m sorry, yes, I meant to say the opposite but I hope you got my meaning. I mean, technically? But I am not sure if you are of the opinion if lower or higher information density is better. IMO, it has little to do with readability unless it’s at the extremes, so I am convinced that it’s a useful metric here. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [February 5, 2024, 10:41pm UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/160 "2024-02-05T22:41:32Z")
Let me clarify then. I agree with [this section of the PEP](https://peps.python.org/pep-0736/#reduces-verbosity). ---
**Author:** ![jagerber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jagerber/32/9412_2.png) [@jagerber](https://discuss.python.org/u/jagerber)\ **Post date:** [February 6, 2024, 12:08am UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/161 "2024-02-06T00:08:30Z")
I would be interested to hear an example of a case when someone would not want to use this feature contrasted with a case where they would want to use this feature. (That is “ I would never use this feature” doesn’t count.) ---
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [February 6, 2024, 1:08am UTC](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432/162 "2024-02-06T01:08:06Z")
I’d avoid using this feature in any case where there was mixed use of transparently passed and non-transparently passed kwargs. It invites asking “was leaving this out intentional?” when something is done differently, and while a comment would explain it wasn’t a mistake, so would just spelling it out. [Previous page](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432.md?page=7) [Next page](https://discuss.python.org/t/pep-736-shorthand-syntax-for-keyword-arguments-at-invocation/43432.md?page=9)