> > In the status quo, we have a filtered loop written as:
> >
> >     for item in items:
> >         if condition:
> >             block


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-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/SRW66ZR6PGSLHVROJHY6C3GR6KOIL2YF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
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/OUN6FEEJ3H6BCXQGWT5ZF77MKDZYVIIK/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to