On Sun, 6 Mar 2022 at 01:55, Christopher Barker <python...@gmail.com> wrote:
>
> On Sat, Mar 5, 2022 at 4:33 AM Paul Moore <p.f.mo...@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...
_______________________________________________
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/BIVNGUTOKYJLXW3LPAOKZWOCHXQNRFRO/
Code of Conduct: http://python.org/psf/codeofconduct/
