
On Thu, 9 Dec 2021 at 11:51, Chris Angelico <rosuav@gmail.com> wrote:
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?
Maybe. I don't use assignment expressions - I don't really have any good uses for them. And no project I maintain is able to use them yet as we support older Python versions. So I'm honestly not sure. I'd be more concerned about confusing := and ==, as both can appear in the same expression. But again I don't know. And I don't know *for certain* about =>. It's a concern, not a showstopper. No-one has yet (as far as I can recall) shown real-life cases, such as a PR against an existing project that changes code to use the new syntax. There's no requirement on a PEP to do that much work up front, so I'm not demanding that you do. But I'll remain concerned about confusability until I see some "real world" evidence like that. And like with assignment expressions, the PEP might still get accepted even though I'm concerned.
Argument defaults look like assignment because it makes sense for them to look like assignment. That's not an accident.
I didn't say it was. But there comes a point when too many things all look like X because they are similar to X, and we run out of easily distinguishable variations. Are we at that point yet? I don't know. Might we be? In my opinion, yes we might. And the PEP should document *your* view on the question, which can be "I think it's fine, but everyone disagrees with me", or "the majority of people on the list think it's OK", or "there were concerns expressed but they were all theoretical and I believe the benefits of this proposal outweigh the theoretical risk". Or whatever. It's your PEP, not mine. Your view is what should be in there.
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.
I think you're (at a minimum) overestimating *my* ability to spot mistakes like this. I'm certain that I've missed similar things in reviews in the past. Maybe I'm not typical. Maybe you're thinking more of people writing their own code, and less about maintainers reviewing externally submitted code. Or maybe projects will define standards and good practices that prohibit over-use of late-bound defaults, or prefer None sentinels where possible, or just impose a general "keep it simple" rule and use that to minimise the risk of confusion. And maybe people will end up cargo culting "you use => for mutable values like [] or {}, and = for everything else" and not actually understanding when values get bound at all. And people do the right thing by accident, so everything is fine (sort of).
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 think your responses above are addressing what I mean by "confusing". But your responses are essentially that you don't agree with me. That's fine, and I'm not demanding that we have to agree here. But to be a fair reflection of the discussion, the PEP should note this concern and be clear that there was disagreement with your position. That is literally all I am asking here. If the PEP ends up containing a section with a list of concerns people have, and your statement that you don't agree with them, that's 100% fine. Maybe it makes the PEP less persuasive. I don't have a problem with that - after all, I'm the one arguing that the status quo is fine. You're the one arguing that the change is worth making, so presumably you believe the section in the PEP that describes the benefits of this change outweighs this.
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.
Rob Cliffe did an excellent summary. Just copy and paste that. If you really don't understand any of the points in spite of his summary and everyone's comments, just note in the PEP that this was the objection and it's not been addressed because you didn't understand what the problem was. And move on.
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.
OK. I don't claim to be in support of the PEP, but I'm only mildly against it (I prefer the status quo). I'll be satisfied if Rob's list of people's concerns is noted in the PEP. You can say these haven't been addressed because you couldn't get a clear understanding of what the precise issue was. I'm fine with that. Or you can say that the concern is noted, but you don't plan on changing the PEP because you don't believe the issue is significant enough. Or whatever, as long as the issue is noted and there's a response. Do that and I'll have nothing further to say. I'll still prefer the status quo, but you don't have to persuade me, you just have to persuade the SC, and as long as the points I've made are noted for the SC's consideration, that's all I ask.
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.
And people don't all agree. So what? Present your case, represent the objections fairly, and that's good enough. As someone said (Jonathan Goble, I think) if we were designing Python now, we'd quite likely have picked late bound defaults as the only behaviour. Early binding has some unfortunate warts. But we didn't, and we're not talking about changing that decision. So the question is whether the existing warts are better or worse than any warts a new solution would have (multiple types of binding behaviour, confusable syntax, etc - you know the drill, you've heard it way too many times now). You think the fix is better than the status quo. Some people here don't (you yourself said "everyone", I think you were being pessimistic, but I think "at least half" is probably fair). Pass the facts to the SC and let them decide. Or drop the idea, if you feel it's not going to succeed. Paul