On Mon, Jul 29, 2019 at 03:12:21PM +0100, Rhodri James wrote:
I'm afraid I agree with Guido. I don't imagine I will use this feature very often, and I can see myself making that mistake every time.
Well, if you don't use this feature very often, you aren't really the audience for the feature and your feedback should therefore be weighted lower *wink* I don't have a strong option one way or another on this feature, but I think we should resist the trap of thinking that every feature must be immediately and intuitively obvious to every reader. There's a hierachy of desirability: 1. syntax that obviously solves a problem; 2. syntax that solves a problem, but it isn't obvious 3. syntax that solves a problem, but may mislead people to think it solves a different problem until they learn better; 4. syntax which doesn't solve the problem; 5. syntax that makes the problem worse. Clearly we prefer 1 or 2 when possible, but 3 ought to be acceptible if the problem being solved is big enough. If this solves a big problem (*if* -- I'm not convinced one way or the other), and there is no better syntax, then we might decide that the cost to people like you is worth the benefit to people like Serhiy. Hypothetically, if Serhiy gets to write more robust, understandable code in fewer lines twice a week, and the cost is that you have to look the syntax up in the documentation once a year, or receive a negative code review from your workmates saying "your for...except block is wrong", so be it. I feel your pain: I don't understand async code when I see it either. But the benefit to those who use it outweighs the confusion it causes people like me. -- Steven