Diez B. Roggisch wrote:
>> Oh well, just wait until Python 2.5 comes out and we get people
>> complaining about the order of the new if statement.
>
> Sad, but true. But I'm a happy camper with list-comps and the new
> if-expression :)
Personally, I'm hoping the unusual order of the if-expressio
Duncan Booth wrote:
> Oh well, just wait until Python 2.5 comes out and we get people complaining
> about the order of the new if statement.
Or rather, the order of the new if _expression_.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
> I think the problem is that y is used before the loop which creates it,
> but x is used after the loop which creates it.
Well, you got me on that. Seems to be a matter of convention all the time.
> People can cope with the expanded loop form where everything it is used
> after it is introduced
Diez B. Roggisch wrote:
>> Which is utterly counter-intuitive, the opposite of Perl, and remains
>> one of the most confusing and surprising things I have encountered in
>> Python so far.
>
> AFAIK stems from mathematics where you write things like
>
> {y | \forall x \in X : \forall y \in x }
>
> Which is utterly counter-intuitive, the opposite of Perl, and remains
> one of the most confusing and surprising things I have encountered in
> Python so far.
AFAIK stems from mathematics where you write things like
{y | \forall x \in X : \forall y \in x }
And so many people consider it pretty
Fredrik Lundh wrote:
> Joel Hedlund wrote:
>
>> I've been thinking about these nested generator expressions and list
>> comprehensions. How come we write:
>>
>> a for b in c for a in b
>>
>> instead of
>>
>> a for a in b for b in c
>>
>> More detailed example follows below.
>>
>> I feel the latter
> a list comprehension works exactly like an ordinary for
> loop, except that the important thing (the expression) is moved to the
> beginning of the statement.
Right. Thanks!
/Joel
--
http://mail.python.org/mailman/listinfo/python-list
Joel Hedlund wrote:
> I've been thinking about these nested generator expressions and list
> comprehensions. How come we write:
>
> a for b in c for a in b
>
> instead of
>
> a for a in b for b in c
>
> More detailed example follows below.
>
> I feel the latter variant is more intuitive. Could any
> for index, color in enumerate(color
> for animal in zoo
> for color in animal):
> # the something more goes here.
> pass
I've been thinking about these nested generator expressions and list
comprehensions. How come we write:
a
Derek Basch wrote:
>> Depending on the types of the containers in question, you could use:
>>
>> len(zoo) * len(animal)
>
> I think this would give me the total iterations but I wouldn't be able
> to get a running count. Correct?
Correct. If you need a running count, maintain a counter (or
Carl Banks wrote:
> But even the clear version isn't as nearly clear and straightforward as
> the nested fors with the counter. I wouldn't forsake that clarity just
> so it isn't "kludgy".
>
>
> Carl Banks
Yeah, looks like using the counters is clearer. Thanks for the opinions
everyone!
Derek B
Derek Basch wrote:
> What is the best way to count nested loop iterations? I can only figure
> to use an index but that seems kludgy.
>
> index = 0
> for animal in zoo:
> for color in animal:
> index += 1
I don't know if it's kludgy, but I do prefer to set counters in the for
statement
Derek Basch wrote:
> index = 0
> for animal in zoo:
> for color in animal:
> index += 1
# assuming there is something more goes here...
>
You could do this, but it kind of depends what the loop *really* looks
like:
for index, color in enumerate(color
Derek Basch wrote:
> Fredrik Lundh wrote:
>>(the real question here is of course why you need the counter. what's
>>the loop doing? if the code you posted is all you have, you can replace
>>it with index = sum(len(animal) for animal in zoo), but I assume you want
>>to do more stuff in there...)
>
Hi Derek
I went for an embarrassingly long time without knowing about
"enumerate()". It doesn't directly answer your question about counting
*within* nests, but I am going to tell you this on the off chance you
don't know yet (and apologies if you do):
This:
count = 0
for animal in zoo:
a =
> Depending on the types of the containers in question, you could use:
>
> len(zoo) * len(animal)
I think this would give me the total iterations but I wouldn't be able
to get a running count. Correct?
Thanks for the reply,
Derek Basch
--
http://mail.python.org/mailman/listinfo/python-lis
Fredrik Lundh wrote:
> what's kludgy with using a counter to count things ?
Ohhh, nothing in particular. Just seeing if there is a better way to do
it.
> (the real question here is of course why you need the counter. what's
> the loop doing? if the code you posted is all you have, you can rep
Derek Basch wrote:
> What is the best way to count nested loop iterations? I can only figure
> to use an index but that seems kludgy.
>
> index = 0
> for animal in zoo:
> for color in animal:
> index += 1
Depending on the types of the containers in question, you could use:
le
Derek Basch wrote:
> What is the best way to count nested loop iterations? I can only figure
> to use an index but that seems kludgy.
>
> index = 0
> for animal in zoo:
> for color in animal:
> index += 1
what's kludgy with using a counter to count things ?
(the real question here is
What is the best way to count nested loop iterations? I can only figure
to use an index but that seems kludgy.
index = 0
for animal in zoo:
for color in animal:
index += 1
Thanks,
Derek Basch
--
http://mail.python.org/mailman/listinfo/python-list
20 matches
Mail list logo
