Syntactic sugar PEP draft #1
Conversation
joshuabambrick
force-pushed
the
sugar
branch
from
b583950 to
90aeb24
Compare
peps/pep-9999.rst
Outdated
| Status: Draft | ||
| Type: Standards Track | ||
| Content-Type: text/x-rst | ||
| Created: 28-Oct-2023 |
There was a problem hiding this comment.
Not clear exactly what date this should be but presumably ~ the date that we create the PR to python/peps
There was a problem hiding this comment.
The Created header records the date that the PEP was assigned a number
https://peps.python.org/pep-0001/#pep-header-preamble
So yes, that will be when opening the PR.
peps/pep-9999.rst
Outdated
| Lines saved 290 247 935 794 | ||
| ===================================================================== ================ ============== =============== ===================== | ||
|
|
||
| .. _a: https://github.com/python/cpython/pull/111423/ |
There was a problem hiding this comment.
May want to move these to the bottom
peps/pep-9999.rst
Outdated
|
|
||
| The syntax is ugly | ||
| -------------------------------------------- | ||
| This objection is by far the most common. On the contrary, we argue that: |
There was a problem hiding this comment.
may want a less argumentative term than 'argue', e.g. 'believe' or 'contend'.
There was a problem hiding this comment.
While there's a lovely pun in calling the word argue "argumentative", it's also not too much of a problem here (eg imagine a mathematician saying "in the debate about pi vs tau, we argue that the elegance of measuring a circle by its diameter outweighs the elegance of radial measures being proportions of an entire turn").
There was a problem hiding this comment.
Fair enough, thanks
peps/pep-9999.rst
Outdated
|
|
||
| Recommendations | ||
| ======================== | ||
| As with any other language feature, the programmer should be judicious about whether using this feature improves their code based on the context. We do not advocate for enforcing a rule of using this feature in all cases where it may be applicable. |
There was a problem hiding this comment.
May want some more concrete recommendations.
Context:
I would appreciate a few examples, in any PEP for this, which show when it is not appropriate. I think that would be enough to guide people away from overzealously trying to enforce this usage on everyone.
There was a problem hiding this comment.
the programmer should be judicious about whether using this feature improves their code based on the context
Sounds weird to me. How about "the programmer needs to exercise their own judgement..."?
Although I think the entire paragraph is a bit too defensive and maybe not needed?
There was a problem hiding this comment.
Sorry I didn't follow up on your comment although I did reword the paragraph. Let me know if you still l
Although I think the entire paragraph is a bit too defensive and maybe not needed?
The context behind adding this was this section of the discussion. There were a few who noted that the universal use of this syntax in all applicable contexts was not advisable based on my linked PR. I generally agree and thought that adding a comment to indicate that we aren't recommending that the use of this feature be enforced universally would help address that concern. There were suggestions at giving some examples as to where it would be most useful but my sense is that these are best left to the discretion of the programmer.
It's recommended by PEP 12:
https://peps.python.org/pep-0012/#general So that's max length of 80, given a start in column 0. |
|
Tip: enable GitHub Actions for your fork to enable some linting: |
|
I think you might have created a PR in your own fork, rather than creating one in the PEPs repository. Once you've dealt with any current suggestions, I recommend remaking the PR (from the same branch in the same fork). The link to do so should, if I've crafted this correctly, be this: python/peps@main...joshuabambrick:peps:sugar At the same time, you could claim yourself a PEP number. We have existing PEPs up to 733 (ahh, my old home bus route... good times), and PEP 734 is claimed by PR python#3523, so PEP 735 would be yours. |
peps/pep-9999.rst
Outdated
| ------------------------------------ | ||
| A common problem is that semantically identical variables have different names depending on their contexts. This syntax would encourage authors to use the same variable name when calling a function as the argument name, which would increase consistency of variable names used and hence also *readability*. | ||
|
|
||
| Naturally extends to dictionaries |
There was a problem hiding this comment.
The heading "Naturally extends" will imply that this syntax could be used in a dictionary display, but what you're proposing is not that. Not sure how to word it, but what you're giving is an elegant use of the dict() constructor to achieve this goal without extending anything syntactically.
There was a problem hiding this comment.
I've renamed this to 'Applicability to dictionary construction'
peps/pep-9999.rst
Outdated
| The feature adds another way of doing things | ||
| -------------------------------------------- | ||
|
|
||
| The same argument can be made against all syntax changes. This is a simple syntactic sugar, much as ``x += 1`` is sugar for ``x = x + 1``. This isn't tantamount to a 'new way' of passing arguments but a more readable notation for the same way. |
There was a problem hiding this comment.
Notably, x += 1 is not mere syntactic sugar for x = x + 1; this can be demonstrated with lists, where x = [1,2]; x += [3,4] will mutate the list in place, but x = x + [3,4] will not. Here's an example where it really truly is syntactic sugar: https://peps.python.org/pep-3135/ Although this particular one, while quite popular, has raised some eyebrows for being too magical and not something to be replicated.
There was a problem hiding this comment.
Sorry I didn't directly reply to this. You are right to point it out.
I tried to address your comment by adding 'when x is an integer'.
I'd be disinclined to point to a more contested syntactic sugar (in fact, I think I'd agree that 3135 is too magical) and I think x += 1 is an example of a widely popular syntactic sugar which some could argue introduces 'another way of doing things'. Plus, while technically __iadd__ can be overridden arbitrarily, in practice it almost always is used to offer syntactic sugar for something which could be written another way.
Please do let me know if you still don't like the wording.
There was a problem hiding this comment.
I think the reason this "feels wrong" is that adding another way of doing things isn't the problem. Python's Zen does not say "there's only one way to do things, you do it our way or you don't do it at all". The Zen says that there is one OBVIOUS way to do things. Given that Python was Turing-complete before this proposal (or any other), by definition ANY proposal is adding another way of doing things. Maybe this entire paragraph is arguing against something that doesn't matter?
Perhaps, if you want to argue about syntactic sugar's benefit, the matrix multiplication operator would be a good place to start. Numpy users for a long time were able to do both types of multiplication, but one of them had an operator and the other was done with a method. Could you do what you wanted? Sure. Was it the way you wanted to write your code? No. And when code isn't as expressive as you'd like, there's the possibility of bugs slipping in.
The benefit of code being obvious is precisely that, in fact: bugs become visible. It is trivially easy to see when you have simple code that's doing a simple task, and you can equally easily see if it's failing to do that task. This proposal achieves that by raising from the concrete "take variable spamination and pass it as the named parameter spamination" to the abstract "pass named parameter spamination as itself".
peps/pep-9999.rst
Outdated
| .. [12] Shorten Keyword Arguments with Implicit Notation: foo(a=a, b=b) to foo(.a, .b) (2023) | ||
| https://discuss.python.org/t/shorten-keyword-arguments-with-implicit-notation-foo-a-a-b-b-to-foo-a-b/33080 | ||
| .. [13] Syntactic sugar to encourage use of named arguments (2023) | ||
| https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217 |
There was a problem hiding this comment.
Where appropriate, it would be better to move these references into inline links.
Two benefits:
- Saves users a click
- They can be a pain to maintain/renumber as the text evolves.
Thanks for the tip. Now passing. |
|
Thanks a lot both for the feedback. Will move this to a PR on the main repo when CI passes. |
|
Actually, before that, let me double check whether you have any tips for what to change (if anything) in CODEOWNERS Update: having read around, I understand that it should be @gvanrossum who offered to sponsor the PEP. Please let me know if you have any issue with this before I create the PR. |
|
I’m fine with that. (Note that I’m neutral about the proposal, I just think that it is worth having a PEP for it.) |
|
Very good write up and good job summarizing the discussion so far! Thanks for your work on this. |
|
(Drive-by comment: "Syntactic sugar" is a very generic concept. This PEP provides syntactic sugar for a specific situation (keyword argument value is a variable with the same name as the keyword). Could you be more specific in the PR title?) |
I understood that we needed a core dev as a sponsor, but apparently that requirement is a bit more relaxed in practice and it was suggested that we may not need one. Please let me know whether you'd prefer to remain as sponsor or not.
That's a good observation. I will try to find something more descriptive while remaining succinct. |
|
Possibly "Keyword argument shorthand notation"? |
|
https://peps.python.org/pep-0001/#submitting-a-PEP says we need at least one of:
Chris is a PEP editor, Guido is a PEP editor and core dev. Right now we meet the criteria with Guido as sponsor. We could also have Chris as sponsor instead of Guido, if you prefer. (There's slightly different semantics to being a co-author - "I propose this PEP" - to a sponsor - "I will assist in the PEP process" - but let's not worry too much about this.) PS maybe we should allow PEP editors to be co-author without a sponsor. After all, the sponsor is there as a PEP process guide, and a PEP editor should be fine without a guide. |
|
Ah I need to set up notifications for github comments.
I'm happy with 'syntax' over 'syntactic sugar' (my thinking was to emphasise that it is not a major new syntax, just a shorter way of writing something already supported but it's probably needlessly verbose). Do you prefer to drop 'for keyword arguments at invocation'? My thinking there was to make the name more specific. |
No no, keep that part, I just thought about abbreviating the beginning of it. Specific is definitely good. |
joshuabambrick
force-pushed
the
sugar
branch
2 times, most recently
from
b471b1a to
177ef6a
Compare
Context: python#3531
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approvalAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History