Andreas Tawn wrote:
Terry Reedy wrote:
For loop variables continue after the loop exits. This is
intentional.
I never knew that and I can't find reference to it in the docs. Can you
help me with the reasons for it?
1. Python's reluctance to multiply scopes without necessity (as other
re
Andreas Tawn wrote:
I don't have experience of too many other languages, but in C++ (and I
guess C)...
That's invalid C (you cannot declare variables in the "for" statement
itself, at least not in C89). And back in the old days, some C++
compilers did in fact leak declarations from "for" lo
> Andreas Tawn wrote:
> > Terry Reedy wrote:
> >> Wrong.
> > Thank you.
> >
> >> For loop variables continue after the loop exits. This is
> >> intentional.
> > I never knew that and I can't find reference to it in the docs.
>
> Interesting starting point. It never occurred to me
> that they
Andreas Tawn wrote:
Terry Reedy wrote:
Wrong.
Thank you.
For loop variables continue after the loop exits. This is
intentional.
I never knew that and I can't find reference to it in the docs.
Interesting starting point. It never occurred to me
that they might not. (So I didn't look for an
Andreas Tawn wrote:
I never knew that and I can't find reference to it in the docs.
the for-in loop does ordinary assignments in the current scope:
http://docs.python.org/ref/for.html
"Each item in turn is assigned to the target list using the
standard rules for assignments, and
Terry Reedy wrote:
>Wrong.
Thank you.
>For loop variables continue after the loop exits. This is
>intentional.
I never knew that and I can't find reference to it in the docs. Can you
help me with the reasons for it?
Drea
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Tawn wrote:
I think a better explanation is that in your original function, x only
existed while the for loop was running. As soon as execution hit the
break statement, x ceased to exist.
Wrong. For loop variables continue after the loop exits. This is
intentional. Mensanator gav
Mensanator wrote:
On Jul 15, 12:36 pm, defn noob <[EMAIL PROTECTED]> wrote:
On Jul 15, 7:28 pm, Mensanator <[EMAIL PROTECTED]> wrote:
On Jul 15, 11:26 am, defn noob <[EMAIL PROTECTED]> wrote:
isPrime works when just calling a nbr but not when iterating on a
list, why? adding x=1 makes it
On Jul 15, 12:36 pm, defn noob <[EMAIL PROTECTED]> wrote:
> On Jul 15, 7:28 pm, Mensanator <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On Jul 15, 11:26 am, defn noob <[EMAIL PROTECTED]> wrote:
>
> > > isPrime works when just calling a nbr but not when iterating on a
> > > list, why? adding x=1 makes i
On Jul 15, 12:28 pm, "Andreas Tawn" <[EMAIL PROTECTED]> wrote:
> >defn noob wrote:
> >> isPrime works when just calling a nbr but not when iterating on a
> >> list, why? adding x=1 makes it work though but why do I have to add
> >> it?
> >> Is there a cleaner way to do it?
>
> >> def isPrime(nbr):
On Jul 15, 7:28 pm, Mensanator <[EMAIL PROTECTED]> wrote:
> On Jul 15, 11:26 am, defn noob <[EMAIL PROTECTED]> wrote:
>
>
>
> > isPrime works when just calling a nbr but not when iterating on a
> > list, why? adding x=1 makes it work though but why do I have to add
> > it?
> > Is there a cleaner wa
On Jul 15, 11:26 am, defn noob <[EMAIL PROTECTED]> wrote:
> isPrime works when just calling a nbr but not when iterating on a
> list, why? adding x=1 makes it work though but why do I have to add
> it?
> Is there a cleaner way to do it?
>
> def isPrime(nbr):
> for x in range(2, nbr + 1):
>
>defn noob wrote:
>> isPrime works when just calling a nbr but not when iterating on a
>> list, why? adding x=1 makes it work though but why do I have to add
>> it?
>> Is there a cleaner way to do it?
>>
>>
>> def isPrime(nbr):
>> for x in range(2, nbr + 1):
>> if nbr % x == 0:
>>
defn noob wrote:
isPrime works when just calling a nbr but not when iterating on a
list, why? adding x=1 makes it work though but why do I have to add
it?
Is there a cleaner way to do it?
def isPrime(nbr):
for x in range(2, nbr + 1):
if nbr % x == 0:
break
if x == n
14 matches
Mail list logo
