The thing is, if block is more than a couple lines, you need to look down to see if there’s an else or any number of elif blocks down there— so this isn’t a clear expression of a filtered iteration after all. Which is why I suggested that:

for item in items:
if not condition:

continue

block

Would be the more direct expression of "filtered iteration" -- still not a whole lot of code, but a bit more awkward.

The other thing that I think is relevant is that comprehensions already have a filtering option -- so while new syntax technically. this proposal would be familiar and create a bit more consistency in the language.

Another half formed idea:

Comprehension can express map-like behavior or map and filter behavior, but no way to filter without a do nothing map.

e.g if you want to only filter, you need to do:

(item for item in items if condition)

I wonder if there's a way to not need to the "item for item" wasted text:

(Item in items if condition)

and

[item in items if condition]

maybe??

it's not legal syntax now. That would then allow:

for item in (item in items if condition):

block

which is almost what's being asked for here. But then the repetition again.

Which leads us back to the OP’s proposal.

I’m actually liking that more now ….

-CHB

> but of course you know that already :-)
>
> So how does the proposal differ?
>
> for item in items if condition:
> block
>
> means what, if it isn't merely a reformatting of the status quo?

Well, if "a + b" is just a reformatting of the BF code you posted,
then yes, it's merely reformatting.

> > > > It's about expressing programmer concepts.
> > >
> > > Right. And composing a for-loop with a if statement expresses that
> > > concept perfectly. As does filter().
> >
> > No, it doesn't.
>
> Wait, you are saying that
>
> for item in filter(predicate, items)
>
> *doesn't* express the concept of a loop with a filter?
>
> Then what does it express?

This does. The trouble is that it ONLY expresses that cleanly in the
case where the predicate is already a function. Otherwise it gets
cluttered with the mess of lambda functions, and it's a lot less
clear.

> And what do you say to the poster who wrote about "filtered iteration":
>
> [quote]
> ... you have this option:
>
> for thing in filter(isinteresting, stuff):
>
> which actually looks good. I think this is a pretty clear indication
> that the idea [filtered iteration] makes sense: functional programming
> languages have an idiom that aligns perfectly with it
> [/quote]
>
> The author of that post certainly sounds like he thinks that the f.p.
> idiom `for item in filter(...)` expresses filtered iteration "perfectly".
>
> (At least for the case where the predicate is a function. I don't think
> he is too fond of lambdas.)

Exactly. Try the versions where that isn't the case, and you'll see why.

We have [x + 1 for x in stuff if x % 3] without lambda functions. We
could have just used [x + 1 for x in filter(lambda x: x % 3, stuff)]
but that's just ugly. There is a huge difference between filter() with
an existing, and usefully-named, predicate, and filter() with a lambda
function (or worse, a single-use global function whose entire purpose
is that filtration).

Lambda functions are extremely useful when they're needed. They are
NOT arbitrary expressions that can be inserted anywhere.

Blub Paradox has you thoroughly in its grip.

ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/SRW66ZR6PGSLHVROJHY6C3GR6KOIL2YF/
Code of Conduct: http://python.org/psf/codeofconduct/