On Tue, Jun 29, 2021 at 07:27:11PM +1000, Chris Angelico wrote:
My point is that the *iteration* isn't any different - the *range* is what's different. A filtered range makes very good sense here. Hence, a disjoint range object (one capable of subtraction) would be an excellent solution to the OP's problem.
I don't think that the OP's problem is *specifically and only* to iterate over disjoint ranges. I think that was just an illustration of the concept. I have no objection to having some sort of ordered integer disjoint ranges, but I don't think that will be sufficient for the OP. [...]
"Process the URLs I want, duh!"
Well, that gets down to the question of what counts as a "sentence". You shouldn't cram everything onto a single line of code just because you can, just as you shouldn't write an English sentence ten pages long.
Ah, you've been reading Daniel Defoe too! *wink* Remember that list comprehensions aren't about saving a line of code. We often split comprehensions over multiple lines to make them more readable. Comprehensions are about making an *expression*. I see no meaningful benefit to cramming a conditional test into the same line as a loop. Current syntax is fine. for item in iterable: if condition: block Putting the condition on the same line as the for doesn't make it an expression. In general, saving one line and one indent is too little benefit to make up for the cost of cramming more details into a single line.
But I don't see a problem with filtered iteration. We currently have a very clunky way of spelling it ("for url in (x for x in iterable if cond):"),
You can write it that way if you want, but why make two loops when you need only one? Isn't that doing more work than necessary? Using an extra loop inside a generator comprehension just to get an if is, I think, an example of being so sharp you cut yourself. -- Steve