On Mon, 2008-09-15 at 14:11 +1200, Greg Ewing wrote:
Cliff Wells wrote:
Not that it's terribly relevant to what you say, but:
'-'.join ( for J in I: YIELD ( for j in J: YIELD j ) )
No, I think you were right the first time. The above looks like it will generate a sequence of iterators, not a flat sequence of j values.
join() takes care of flattening the final yielded iterator. The first one was actually wrong in that it didn't solve the presented problem.
x = [ J [ a ] for a in b if c ]
vs
x = for a in b: if c: continue J [ a ]
The complexity has barely increased and yet the second form is already more readable
That's a matter of opinion. If you lay out the first one as
x = [ J [ a ] for a in b if c ]
there's not much difference between them.
I thought I'd been saying that all along ;-) I think listcomps are only a *clear* win when they are presented in their simplest form, otherwise it really is just preference. Get into nested listcomps and the readability (or more to the point the comprehensibility) pretty much vaporizes.
Not to mention, the listcomp's placement of the yielded result before the loop and condition only works well when it's a very simple expression. It doesn't scale well with complexity (not that I think it was meant to).
You're right, it's not meant to. It's meant for the simple cases where all the syntactic overhead of a full for-statement and list appending code swamps the content. Given that, adding any extra syntactic baggage, even just a 'continue' keyword, reduces its effectiveness for its intended purpose.
So then maybe what we could agree on is that there's a place for both?
Also, I think it reads quite nicely with the expression at the beginning. It's modelled after the mathematical notation for describing sets:
{x : some conditions on x}
Sure, I think listcomps have a place. I still maintain that they are logically redundant if you have if-expressions (not to mention less flexible), but if we decided they were justifiable syntactic sugar then that's fine too. Cliff