On Thu, Dec 9, 2021 at 8:45 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 8 Dec 2021 at 23:40, Chris Angelico <rosuav@gmail.com> wrote:
I have attempted to explain the syntax. What is confusing?
def f(x=spam): ...
def f(x=>spam): ...
Are we using the term "confusing" in different ways? I'm saying that it's easy to confuse the two forms = and =>, as they look very similar, and in many (nearly all?) cases, do exactly the same (although I assume => would be slower, as I doubt the compiler would be able to tell that it could optimise away an unnecessary late binding).
Are = and := confusing? They are also very similar, and they have some subtle distinctions. Is it a problem for two different operators to look similar when they do very similar things? Argument defaults look like assignment because it makes sense for them to look like assignment. That's not an accident.
It's not that I find the syntax or semantics hard to understand, but that the two forms are easily confused with each other. And it's not that I can't see which is which on a careful reading. It's in a maintenance context where I imagine the issues - a PR that includes a typo using = instead of =>, which doesn't get picked up in code review because the reviewer missed the typo. Or a function that uses a default of =[] when =>[] was intended, and gets a subtle timing error that the tests don't pick up and reviewers misread as "using that late binding syntax" rather than thinking "=[] is a known gotcha".
If this is accepted, it will become a standard idiom to see "=>[]" or "=>{}" or whatever, and seeing "=[]" will continue to look wrong. I think you're underestimating people's ability to understand code. But maybe we ARE using the term "confusing" in different ways. Maybe I'm trying to respond to completely the wrong thing. If the concern is that the new syntax is "confusing" but I'm interpreting that word wrongly, please clarify.
I'm not sure what concerns need to be addressed, because I don't understand the concerns.
Fair, but you can state them, surely? Even if you're just copying what people say into the PEP, and noting that these are open issues that the PEP author cannot address without further explanation of the issue, that's better than having nothing (and having the same objections raised over and over again). At the moment the PEP doesn't even *have* an "open issues" section.
No, I can't, because every time I try to pin down actual issues, they slip away. I can't nail jelly to the PEP.
EVERYONE is arguing against the proposal.
So your response to my concern that opinion is divided on the PEP, is to say that actually, no-one likes it? I get that you're frustrated, but that doesn't seem useful.
The problem is that even people who claim to be in support of it are arguing against it. That's what makes it incredibly hard to figure out what concerns are still open.
Maybe we don't need any new features in Python. Maybe Python 3.10 is already the perfect language, and we should just preserve it in amber.
I assume that's frustration speaking, because no-one's saying that. Sure, the number of changes that meet the bar for inclusion has gone down. The bar is higher when you're the world's most popular programming language, after all. And fixing imperfections that people have survived with for years can be a hard sell (I still have hope that someday we'll get a better spelling for lambda, though!) But if we give up on all innovation as a result, we won't be the most popular language for long :-(
Exactly. And this particular issue is fixing an issue that people point to as a gotcha - "be careful of mutable default arguments" or even "mutable values don't work in argument defaults" (which I see all too often). With a good response of "they behave that way if you write =>[] instead of =[]", it still looks and feels like an argument default, but it has the slightly different behaviour that people expect, and all is well. ChrisA