This is a discussion thread for PEP 736 which is currently in draft.
Previous threads have generated a lot of conversation already so it would be really appreciated if you could read the PEP and previous discussion before contributing and confirm whether your suggestion has already been addressed satisfactorily.
Thanks so much to everyone who has contributed their thoughts so far. Some minor suggestions have been omitted from this post for brevity but if you feel I’m missing a critical point that was previously made, please send a Discuss message.
The following feedback on the PEP itself has been noted and I will do my best to address it in a subsequent edit:
- Correct ‘named variables’ to ‘named arguments’
- Clarify our response to ‘explicit is better than implicit’ objection
- Address the balance of coupling semantically distinct variables vs avoiding desynchronising semantically equivalent ones
- Explain the impact on editing code and IDEs
The publication of the PEP sparked a few conversations on the previous thread. I’ll mention them and give my own current take here, but if you have substantive contributions which will further the discussion on these points, please do offer them here.
Much of the previous discussion has centred on the particular syntax chosen for the PEP. The most common alternative proposal is
f(x, *, y). I think this is the strongest alternative that has been proposed as it closely resembles the keyword-only syntax of function definitions and it was the second most popular in the poll.
I’m not personally wedded to the syntax presented in the PEP (indeed that syntax is different from the one I originally proposed). However, so far, I haven’t seen any concrete benefits of any alternative which are not already described in the PEP, instead most of the emphasis is on stylistic preference. The weight of merits as presented in the PEP still seem stronger for the
I recognise that the explanation given in the PEP is inadequate and that it is true that, in an obvious sense, the argument value is ‘implicit’ in our proposed syntax. However, I do not think that this is what the Zen of Python is trying to discourage.
In the sense that I take the Zen to be referring to, keyword arguments (for example) are objectively more explicit than positional arguments where the argument name is omitted and impossible to tell from the local context. Conversely, the syntactic sugar for integers
x += 1 is not more implicit than
x = x + 1 in this sense, even though the variable is omitted from the right hand side, because it is immediately obvious from the local context what it is. The syntax proposed in this PEP is much more analogous to the second example, and is designed in part to encourage use of keyword arguments which are more explicit than positional ones.
I’m unconvinced that we’re going to make any more progress on this so I’d not recommend much more discussion on this area. I will edit the PEP to be clearer.
As ever, all syntax has the potential for misuse and so should be used judiciously. In this case, if a parameter and its value have the same semantics in both contexts, that may suggest that using this new syntax is appropriate. If not, that may suggest that they should have different names. Our analysis of popular repos showed that the former is at least very common.
The status quo in Python encourages developers (e.g., me, at a minimum) to use shorter and less descriptive names to save keystrokes or use positional arguments to reduce visual clutter. We argue that this new syntax presents a valuable nudge towards use of keyword arguments and will ameliorate the risk of desynchronisation of semantically equivalent variables in different contexts which harms readability. Whether the risk of misuse outweighs the benefits of the proposed syntax enumerated in the PEP (the degree of which is hard to measure, as with any hypothetical change) is a judgement for the SC to make. I’m open to suggestions of objective evidence that could help shed light on this.