On Thu, Mar 03, 2022 at 10:30:32PM +1100, Chris Angelico wrote:
> On Thu, 3 Mar 2022 at 21:14, Steven D'Aprano <st...@pearwood.info> wrote:
> > What did I say that made you think I denied the existence of filtered
> > iteration? Was it the post where I pointed out we've been able to do
> > filtered iteration going back to Python 1.x days?
>
> ANYTHING can be done by composing concepts. We don't need anything
> more advanced than Brainf*. Why do we have better concepts? Because
> they do a better job of expressing abstract concepts.
They also do a better job of expressing *concrete* concepts, like
addition.
I believe this is a BF program to read two single digit numbers, add
them, and print the result:
,>,[<+>-]<------------------------------------------------.
And if you think that is nasty, you should see Malbolge.
I don't think that the difference between the status quo and the proposal:
# status quo for a filtered loop
for item in items:
if condition:
block
# proposal for a filtered loop
for item in items if condition:
block
is comparable to the difference between BF and Python. How about you?
> > To be clear, there are lots of concepts in coding. Not all of them
> > require their own specialised syntax. We don't have specialised syntax
> > for a try...except block inside a loop, we use composition by putting a
> > try...except block inside a for loop.
> >
> > Composition of statements is not a bug to be fixed.
>
> Indeed, but I'm putting the viewpoint - which a number of other people
> have also put - that filtered iteration DOES deserve a better way of
> expressing it.
Better than the three or four ways we already have? Okay.
To me, comprehensions were a significant improvement over the Python 1.x
status quo, because they permitted us to write list builders as
expressions, which could then be embedded directly in statements or
other expressions without needing temporary variables.
Generators and iterators were significant improvements, because they
allow us to do things we couldn't do (easily, or at all) before.
Context managers were another significant improvement.
Aside from saving one line and one indent level, what *significant*
improvement does the proposed change give us? This is not a rhetorical
question.
> > Nobody said that the idea of filtered looping doesn't make sense.
> > They're only questioning whether it needs its own syntax instead of
> > composing existing syntax.
>
> Yes. And it keeps coming up, so I think you should probably
> acknowledge the fact that maybe, just maybe, this is more significant
> than "one newline".
I have repeatedly said that it also saves an indent level. I never
bothered to mention the saving of one colon, because I thought that even
for Python-Ideas that would be too trivially unimportant to mention.
What else does it give us? The one-line proposal and the two line status
quo express exactly the same concept: a loop with a filter.
The functional programming idiom using filter() is even better at
expressing that concept, at least for the case where the predicate is a
function, but many people have an unfortunate aversion to f.p. idioms
and so won't use it.
> > > You're thinking FAR FAR too concretely about this. It's not about
> > > newlines.
> >
> > Of course it is. The whole point of the proposal is to move a two line
> > statement into a single line. Earlier in this thread, I pointed out that
> > this proposal adds no new functionality to Python. It doesn't allow us
> > to do anything we can't already do, or even make it easier to do it.
> >
> > Literally all it saves is a newline and an indent.
>
> No, it is not. It is expressing the concept of filtered iteration.
Which the existing idioms already do. So we have three or four ways of
expressing filtered iteration, and the proposal is for another way of
expressing filtered iteration which differs in that it saves a line and
an indent level, and let's not forget that vitally important colon.
Is there any other difference that I have missed?
> Do you, or don't you, accept that that is a concept? One moment you say
> that it is a concept but you think it shouldn't get dedicated syntax,
Yes. Many concepts don't have dedicated syntax.
We don't have dedicated syntax for, say, recursion. (We just use a
function call.) Or for getting the length of a sequence (another
function call). Or sorting.
> then the next, you imply that it isn't even a concept,
Citation required.
> and all we're
> doing is reformatting code. That is simply not the case.
Okay, now we're getting somewhere! So there is a semantic difference
between the status quo and the new proposal. I'm sorry, I missed that!
Mea culpa. Please take pity on me and explain what I have missed.
In the status quo, we have a filtered loop written as:
for item in items:
if condition:
block
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?
> > > 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?
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.)
https://mail.python.org/archives/list/python-ideas@python.org/message/JQGDLV5UVVVFTL7QHN5REOOPHQUX6XG5/
--
Steve
_______________________________________________
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/HAKBRI5MXNYWAPRZXWQTDKHY4AF66WC3/
Code of Conduct: http://python.org/psf/codeofconduct/
