Encourages use of named arguments

By reducing the visual noise that established keyword argument syntax can cause,this syntax would encourage the use of named arguments, thereby increasingreadability and reducing bugs from argument transposition.

Reduces verbosity

By minimising visual noise and in some cases lines of code, we can increasereadability.

Encourages consistent variable names

A common problem is that semantically identical variables have different namesdepending on their contexts. This syntax would encourage authors to use the samevariable name when calling a function as the argument name, which would increaseconsistency of variable names used and hence improve readability.

Highlights arguments not following this pattern

With the current syntax, function calls where many arguments are forwarded fromthe local context can make other argument values easy to miss due to the visualnoise. For example:

add_middleware(excluded_urls=excluded_urls,server_request=server_request,client_request=client_request,client_response=client_response,span_details=_get_span_details(),tracer=tracer,meter=meter,)

With this syntax, the exceptional arguments become easier to identify:

add_middleware(excluded_urls=,server_request=,client_request=,client_response=,span_details=_get_span_details(),tracer=,meter=,)

Applicability to dictionary construction

This syntax can be applied to dictionary construction where a similar patternfrequently occurs (where dictionary keys are identical the names of thevariables assigned as their values),{"x":x,"y":y} ordict(x=x,y=y).With this feature, this can now also be trivially written asdict(x=,y=).Whether to further support similar syntax in dictionary literals is an openquestion beyond the scope of this PEP.

f(a,b,*,x)

On a few occasions the idea has been floated to borrow the syntax fromkeyword-only function definitions.

In favour of this proposal:

• This syntax is familiar from its use to require keyword-only arguments infunction definitions.
• A poll of Python developersindicates that this is the second most popular syntax among those proposed.

However, we object that:

• For any given argument, it is less clear from local context whether it ispositional or named. The* could easily be missed in a long argument listand named arguments may be read as positional or vice versa.
• It is unclear whether keyword arguments for which the value was not elided mayfollow the*. If so, then their relative position will be confusinglyarbitrary, but if not, then an arbitrary grouping is enforced betweendifferent types of keyword arguments and reordering of arguments would benecessary if only one name (the argument or its value) was changed.
• The use of* in function calls is well established and this proposal wouldintroduce a new effect which could cause confusion. For example,f(a,*x,y) would mean something different thanf(a,*,x,y).

f(=x)

In favour of this form:

• The prefix operator is more similar to the established*args and**kwargs syntax for function calls.
• It draws more attention to itself when arguments are arranged vertically. Inparticular, if the arguments are of different lengths it is harder to find theequals sign at the end. Moreover, since Python is read left to right, the useof this feature is clearer to the reader earlier on.

On the contrary:

• While the prefix version is visually louder, in practice, there is no need forthis feature to shout its presence any more than a typical named argument. Bythe time we read to the= it is clear that the value is filled inautomatically just as the value is clear in the typical keyword argument case.
• Semantically, this form communicates ‘here is a value, fill in the parameter’which is not what we want to convey.
• It is less similar to f-string syntax.
• It is less obvious that arbitrary expressions are invalid, for example,f(=a+b), since such expressions are acceptable after the equals sign inthe current keyword argument syntax but not before it.

f(%x) orf(:x) orf(.x)

Several flavours of this syntax have been proposed with the prefix formsubstituting another character for=. However, no such form has gainedtraction and the choice of symbol seems arbitrary compared to=.Additionally, there is less precedent in terms of existing language features(such as f-string) or other languages (such as Ruby).

The syntax is ugly

This objection is the most common. On the contrary, we argue that:

• This objection is subjective and many community members disagree.
• A nearly-identical syntax is already established for f-strings.
• Programmers will, as ever, adjust over time.

The feature is confusing

We argue that:

• Introducing new features typically has this impact temporarily.
• The syntax is very similar to the establishedf'{x=}' syntax.
• The feature and syntax are familiar from other popular modern languages.
• The expansion ofx= tox=x is a trivial feature and inherentlysignificantly less complex than the popular*arg and**kwargexpansions.
• This particular syntactic form has been independently proposed on numerousoccasions, indicating that it is the most obvious[1][2][6].

The feature is not explicit

We recognise that, in an obvious sense, the argument value is ‘implicit’ in thisproposed syntax. However, we do not think that this is what the Zen of Python isaiming to discourage.

In the sense that we take the Zen to be referring to, keyword arguments (forexample) are more explicit than positional arguments where the argument name isomitted and impossible to tell from the local context. Conversely, the syntacticsugar for integersx+=1 is not more implicit thanx=x+1 in thissense, even though the variable is omitted from the right hand side, because itis immediately obvious from the local context what it is.

The syntax proposed in this PEP is much more closely analogous to thex+=1example (although simpler since we do not propose to introduce a new operation).Moreover, by removing the barrier of visual noise introduced by the existingkeyword argument syntax, this syntactic sugar will encourage the use of keywordarguments over positional ones, making typical Python codebases more explicit ingeneral.

The feature adds another way of doing things

The same argument can be made against all syntax changes. This is a simplesyntactic sugar, much asx+=1 is sugar forx=x+1 whenx is aninteger. This isn’t tantamount to a ‘new way’ of passing arguments but a morereadable notation for the same way.

Renaming the variable in the calling context will break the code

ANameError would make the mistake clear in the large majority cases. Theremay be confusion if a variable from a broader scope has the same name as theoriginal variable, so noNameError would be raised. However, this issue canalso occur with keyword arguments using the current syntax (although arguably,this syntactic sugar could make it harder to spot). Moreover, having variableswith the same name in different scopes is broadly considered to be bad practiceand is discouraged by linters.

Code editors could highlight the issue based on static analysis –f(x=) isexactly equivalent to writingf(x=x). Ifx does not exist, moderneditors have no problem highlighting the issue.

This syntax increases coupling

We recognise that, as ever, all syntax has the potential for misuse and soshould be applied judiciously to improve codebases. In this case, if a parameterand its value have the same semantics in both contexts, that suggests that usingthis syntax is appropriate and will help ameliorate the risk of unintentionaldesynchronisation which harms readability.

However, if the two variables have different semantics, that suggests that thisfeature should not be used (since it encourages consistency) or perhaps that oneor both of the variables should be renamed.

Using a plain text editor

Editing with a plain text editor should generally be unaffected.

When renaming a variable using a ‘Find-Replace’ method, where this syntax isused the developer will come across the function argument at invocation (as theywould if this syntax was not used). At that point, they can, as usual, decidewhether to update the argument as well or expand to the fullf(x=x) syntax.

As with the current syntax, a ‘Find-Replace All’ method would fail since thekeyword argument would not exist at function definition, in the vast majorityof cases.

If the developer leaves the argument name unchanged and forgets to update itsvalue, aNameError will typically be raised as described inRenaming the variable in the calling context will break the code.

Proposals for IDEs

In response to community feedback, we include some suggestions regarding howIDEs could handle this syntax. However, we defer to the domain expertsdeveloping IDEs to use their discretion.

Most considerations are made simple by recognising thatf(x=) is justsyntactic sugar forf(x=x) and should be treated the same as at present.