On Thursday, November 3, 2016 at 4:30:00 AM UTC-4, Steven D'Aprano wrote: > On Thursday 03 November 2016 17:56, arthurhavli...@gmail.com wrote: > > I would propose this syntax. (TODO: find appropriate keywords I guess): > > > > lst.map x: x*5 > > lst.filter x: x%3 == 1 > > I think the chances of Guido accepting new syntax for something as trivial as > this with three existing solutions is absolutely zero. > > I think the chances of Guido accepting new list/dict methods for in place map > and/or filter is a tiny bit higher than zero.
To my eyes, this proposed syntax is completely foreign. "lst.map" looks like attribute or method access on lst, but there's no operation on the result, or function call. They implicitly assign back to lst, with no recognizable syntax to indicate that they do (= or "as" is the usual marker). While mapping and filtering are common operations, I'm not sure mapping and filtering and then reassigning back to the original sequence is especially common. It's certainly not common enough to deserve completely new syntax when the existing methods already exist. Part of the problem here is that you value explicitness, but also are trying to reduce redundancy. When you say that lst occurs twice in your examples, what I see is that it occurs twice because it's being used for two different things: it is the source of the data, and it is also the target for the result. I think it is good to have it appear twice in this case, especially since there's no reason to think it will usually be used for both purposes. How do I do exactly the same data manipulation, but then assign it to lst2 because I belatedly realized I wanted both the before and after list? Under your proposed syntax, I would have to completely rewrite the line to use a different filtering mechanism because now I need to unbundle the filtering and the assignment. That seems unfortunate. You've done the right thing by bringing the proposal here. I think it is useful to see how people approach the language, and where they want changes. Discussing the pros and cons is a good way to get a deeper appreciation both for the language and the rationale for its design. But I don't think this proposal has a chance of moving forward. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
