On Thu, Mar 03, 2022 at 10:30:32PM +1100, Chris Angelico wrote:
On Thu, 3 Mar 2022 at 21:14, Steven D'Aprano <steve@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/JQGDLV... -- Steve