On Wed, 8 Dec 2021 at 23:40, Chris Angelico <ros...@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). 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". Note that the same argument applies for a lot of alternative spellings as well: :=, >=, =:, ?=, all have the same problem. It's more the structure that's the issue. And yes, I know people don't confuse a+b and a-b. This is a people problem, so it can't be dealt with by applying a set of objective, mechanical rules on what works and what doesn't. But that doesn't mean it's all opinion. User interface design (which is what this is, essentially) is *hard*, unfortunately. I suspect your next question will be "what do you expect me to do about that?" And I'll be honest, I don't know. It's your proposal, not mine. Reconsider some of the other proposals for syntax? Explore approaches other than "the syntax is deliberately similar to the existing early-bind syntax" which is stated as a design principle in the PEP? Note the concern in the PEP, with some concrete details on what proportion of people in the discussion believed it would be an issue, and state that you don't consider it a significant risk? Sometimes the colour of the bikeshed *is* important. But you get to pick. > 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. > Maybe I'm just getting caught up on all the > side threads about "deferreds are better" and "it should be a magical > function instead" and I've lost some of the basics? Feel free to > repost a simple concern and I will attempt to respond. Well, I did that when you asked the last time. Maybe you don't think my concerns are "simple", but I don't know what to do about that - if you are saying my concerns "aren't stated simply enough" for a response, I'm out of ideas for how to proceed. If my ideas were that simple to state, they'd be simple to fix, and I wouldn't be worried about them. I could explain any one of my objections in more detail. But how would a paragraph or two of explanation "simplify" things? > > Yes, many of the concerns are somewhat subjective, and many of them > > are subject to a certain amount of interpretation. That's the nature > > of this sort of issue. If I said to you that the biggest issue here > > was that "in the group of people on python-ideas who were motivated > > enough to get involved in discussions, about half of the participants > > were arguing against the proposal"ยน would that be a concrete enough > > objection for you? Count it as my 5th objection, if you like. I know > > we're not putting the PEP to a vote here, but proposed changes *are* > > supposed to achieve a certain level of consensus (in the normal course > > of events - of course the SC can approve anything, even if it's hugely > > unpopular, that's their privilege). > 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. > Quite frankly, I'm just > about ready to throw the whole thing in, because this entire thread > has devolved to complaints that are nearly impossible to respond to - > or are just repetition of things that ARE responded to in the PEP. OK, well I've given my reservations (and note that I have repeatedly used the terms "reservations" and "concerns" rather than "objections", and that's deliberate). I won't continue to discuss or clarify them unless you have specific questions, as I feel that doing so will just increase your frustration here, and I don't want to do that. But if you *do* feel there's merit in trying to address points that have been raised, feel free to pick one of my points and ask more detailed questions, if you think that would help. I don't think it's true that everyone objects, though. There are some posters who support the proposal enthusiastically. And yes, there's a lot of debate, but it feels to me like it's mostly trying to be constructive, but people are getting frustrated because they can't get their point across. > 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 :-( Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3LVXDHIDGVHIPVLMP6X4YFJD2XXNBYQ7/ Code of Conduct: http://python.org/psf/codeofconduct/
