On Sun, 6 Mar 2022 at 01:55, Christopher Barker <pythonchb@gmail.com> wrote:
On Sat, Mar 5, 2022 at 4:33 AM Paul Moore <p.f.moore@gmail.com> wrote:
for thing in filter(is_interesting, this_collection): ...
That seems pretty non-clunky. Is the issue here that "filter" is not sufficiently well-known? Or that you don't want to name the is_interesting function, and lambdas are "too clunky"? This feels like another case where the general dislike of lambda results in people wanting special-case syntax so they can avoid either writing a throwaway function, or using lambda.
Speaking for me -- it's not a dislike of lambda -- it's a dislike of the map / filter approach vs comprehensions in general. I guess you could say I have a dislike for lambda -- but really it's a dislike for having to create a function when an expression will do ;-) -- and lamda only supports expressions, so it will always do.
This entire conversation -- at least from the side of the skeptics -- seems to be ignoring comprehensions:
Personally, I'm certainly not ignoring comprehensions. "for thing in (x for x in collection if is_interesting(x))" uses comprehensions just fine, if you don't like the verbosity of "x for x in", then that's an issue with comprehensions, not a reason why comprehensions don't address this issue, surely? (Personally, I find the repetitiveness of "x for x in" mildly annoying, but not enough to put me off comprehensions[1]). I'm offering map/filter precisely *because* the people arguing for this construct don't seem to like the idea of using a comprehension. So IMO it's the supporters of the idea who are ignoring comprehensions (or don't want to use them for some unclear reason that seems to boil down to "it doesn't look nice"). Syntactically, the proposal is fundamentally just removing "x for x in" and a set of parentheses, in the special case where you don't also want to do a calculation on the item - you need to go back to the comprehension form if you need "for thing in (x.interesting_bit for x in collection if is_interesting(x))". Or, of course, you split it up: for x in collection: if not is_interesting(x): break thing = x.interesting_bit ... But maybe I just differ in how much I feel comfortable cramming into a single line...?
If we all thought that map and filter were perfectly adequate, comprehensions never would have been added at all. And not only were comprehensions added, but both a looping and filtering mechanism was added at the same time. Let's imagine for the moment that the filtering was not yet added -- then say the way to run a filtered loop in a comprehension would be:
[expr for thing in filter(lambda thing: expr, an_iterable)]
Would anyone really largure that there would be no point in adding the filter explicitly to get to (what we do have now):
[expr1 for thing in an_iterable if expr2]
The other relevant point is that adding an `if` to the for loop is new syntax, yes, but it mirrors the comprehension syntax very closely -- so is not nearly the cognitive load that most syntax additions are.
Just because comprehensions are good, doesn't mean *everything* needs to look like them. Comprehensions are good because they are *expressions*, not because they are one-liners. For statements aren't expressions, they are statements, so having the filter be an extra statement isn't the problem that it is for a comprehension.
In fact, I imagine if newbies were to learn about comprehensions first, they'd be surprised that there was no if allowed in for loops.
Maybe, if that were a compelling argument, why don't *other* languages with comprehensions also have for loops with an if clause?
Yes, this is a fairly minor improvement, but to me it's not adding syntax to "save a line" "or not have to use lambdas" -- but rather it's adding syntax to make it possible to express a particular concept in a way that is clear, obvious, and more consistent with the rest of the language (i.e. comprehensions).
I was +0, but after this discussion, now +1.
I was, and remain, indifferent to the idea. I'm not against, but I don't see the point of all the energy being spent trying to persuade people this should be added. If anything, trying to explain why I find the arguments given in favour of the proposal weak, is simply making me less interested in the proposal - so I think the main result of this discussion is likely to be just to push people to more entrenched positions, and not change many minds. Which in general, is quite likely why discussions like this on python-ideas are so frustrating. IMO, if someone is interested enough, they can write a PEP. If the arguments are strong enough, there's no need for everyone on python-ideas to agree with the proposal. And conversely, if the key argument is just that everyone on python-ideas thought it was a good idea, it's still probably going to get rejected because PEPs aren't simply popularity contests... Of course, if people just want to debate, that's fine but it won't result in anything happening (except the previously noted entrenching of positions) ;-) Paul [1] Straw man proposal for removing this redundancy: allow leaving off the initial expression if it's the same as the for-variable, so (for x in collection if condition) is the same as (x for x in collection if condition). It saves almost nothing in terms of typing, so I'm unconvinced it's worth it, but maybe it'll satisfy the "it's too verbose" crowd...