Dave Angel wrote:
> 2) In original C, and I think in C++, the lifetime of i lasted long
> after the loop ended.
> for (int i=0; i< limit; ++i)
> {
>z += i;
> }
> i is still valid after this curly brace
>
> In C99, and at least in later C++, the scope of i ends w
On Sat, 17 Apr 2010 17:23:45 +0200, Alain Ketterlin wrote:
> Steven D'Aprano writes:
>
>> On Sat, 17 Apr 2010 12:05:03 +0200, Alain Ketterlin wrote:
>>
I don't know of any language that creates a new scope for loop
variables, but perhaps that's just my ignorance...
>>>
>>> I think Pas
There's no RightAnswer(tm), just our best guess as to what is the most
useful behavior for the most number of people.
+1 QOTW
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano writes:
> On Sat, 17 Apr 2010 12:05:03 +0200, Alain Ketterlin wrote:
>
>>> I don't know of any language that creates a new scope for loop
>>> variables, but perhaps that's just my ignorance...
>>
>> I think Pascal and Modula-2 do this, Fortran does this, as well as Ada.
>
> Pasca
On Sat, 17 Apr 2010 12:05:03 +0200, Alain Ketterlin wrote:
>> I don't know of any language that creates a new scope for loop
>> variables, but perhaps that's just my ignorance...
>
> I think Pascal and Modula-2 do this, Fortran does this, as well as Ada.
Pascal doesn't do this.
[st...@sylar pas
Steven D'Aprano writes:
> On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
>
>>>Nevertheless, it is a common intuition that the list comp variable
>>>should *not* be exposed outside of the list comp, and that the for-loop
>>>variable should. Perhaps it makes no sense, but it is very common --
>>>I
Steven D'Aprano wrote:
On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
In article <4bb92850$0$8827$c3e8...@news.astraweb.com>, Steven D'Aprano
wrote:
Nevertheless, it is a common intuition that the list comp variable
should *not* be exposed outside of the list comp, and that the for-l
* Steven D'Aprano:
On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
In article <4bb92850$0$8827$c3e8...@news.astraweb.com>, Steven D'Aprano
wrote:
Nevertheless, it is a common intuition that the list comp variable
should *not* be exposed outside of the list comp, and that the for-loop
variable
Steven D'Aprano wrote:
On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
In article <4bb92850$0$8827$c3e8...@news.astraweb.com>, Steven D'Aprano
wrote:
Nevertheless, it is a common intuition that the list comp variable
should *not* be exposed outside of the list comp, and that the for-loop
vari
On Fri, Apr 16, 2010 at 5:20 PM, Steven D'Aprano
wrote:
> On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
>> In article <4bb92850$0$8827$c3e8...@news.astraweb.com>, Steven D'Aprano
>> wrote:
>>>Nevertheless, it is a common intuition that the list comp variable
>>>should *not* be exposed outside o
On Fri, 16 Apr 2010 08:48:03 -0700, Aahz wrote:
> In article <4bb92850$0$8827$c3e8...@news.astraweb.com>, Steven D'Aprano
> wrote:
>>
>>Nevertheless, it is a common intuition that the list comp variable
>>should *not* be exposed outside of the list comp, and that the for-loop
>>variable should.
On Apr 3, 3:30 am, Alain Ketterlin
wrote:
> Hi all,
>
> I've just spent a few hours debugging code similar to this:
>
> d = dict()
> for r in [1,2,3]:
> d[r] = [r for r in [4,5,6]]
> print d
>
> THe problem is that the "r" in d[r] somehow captures the value of the
> "r" in the list comprehensi
In article <4bb92850$0$8827$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
>
>Nevertheless, it is a common intuition that the list comp variable should
>*not* be exposed outside of the list comp, and that the for-loop variable
>should. Perhaps it makes no sense, but it is very common -- I'v
On Sun, Apr 4, 2010 at 5:20 PM, Paul Rubin wrote:
[...]
>
> d[r] = list(r for r in [4,5,6])
>
This have a slightly performance difference. I think mainly the
generator's next() call.
In [1]: %timeit list(r for r in range(1))
100 loops, best of 3: 2.78 ms per loop
In [2]: %timeit [r for r
Lie Ryan wrote:
in python there is only a flat
local namespace and the names resolver becomes a thousand times simpler
No, it doesn't. The compiler already has to deal with multiple
scopes for nested functions. There may be some simplification,
but not a lot.
The main reason is linguistic. Hav
On 2010-04-06 09:34:04 -0700, Lie Ryan said:
in python there is only a flat
local namespace and the names resolver becomes a thousand times simpler
(and faster).
This hasn't been true for a long time. Yes, local variables are
optimized to be indexed in an array, but Python has nested scopes f
On 04/06/10 18:42, Alain Ketterlin wrote:
> Alain Ketterlin writes:
>
>> d = dict()
>> for r in [1,2,3]:
>> d[r] = [r for r in [4,5,6]]
>> print d
>
> Thanks to Chris and Paul for the details (the list comp. r actually
> leaks). I should have found this by myself.
>
> My background is more
Steven D'Aprano writes:
>> d = dict()
>> for r in [1,2,3]:
>> d[r] = [r for r in [4,5,6]]
>> print d
>
> This isn't directly relevant to your problem, but why use a list
> comprehension in the first place? [r for r in [4,5,6]] is just [4,5,6],
> only slower.
Sure. But I've actually spent s
Alain Ketterlin writes:
> d = dict()
> for r in [1,2,3]:
> d[r] = [r for r in [4,5,6]]
> print d
Thanks to Chris and Paul for the details (the list comp. r actually
leaks). I should have found this by myself.
My background is more on functional programming languages, that's why I
thought th
On 2010-04-04 14:50:54 -0700, Paul Rubin said:
Alain Ketterlin writes:
d[r] = [r for r in [4,5,6]]
THe problem is that the "r" in d[r] somehow captures the value of the
"r" in the list comprehension, and somehow kills the loop interator.
Yes, this is a well known design error in Python 2.x.
On 2010-04-04 17:01:20 -0700, Steven D'Aprano said:
On Sun, 04 Apr 2010 05:50:01 -0700, Ethan Furman wrote:
Yes, this has been fixed in later revisions, but I'm curious to know
what led you to believe that a list comprehension created a new scope.
I don't that was ever promised.
Common sens
On Sun, 04 Apr 2010 14:50:54 -0700, Paul Rubin wrote:
> Alain Ketterlin writes:
>> d[r] = [r for r in [4,5,6]]
>> THe problem is that the "r" in d[r] somehow captures the value of the
>> "r" in the list comprehension, and somehow kills the loop interator.
>
> Yes, this is a well known design
On Sun, 04 Apr 2010 05:50:01 -0700, Ethan Furman wrote:
>>>Yes, this has been fixed in later revisions, but I'm curious to know
>>>what led you to believe that a list comprehension created a new scope.
>>>I don't that was ever promised.
>>
>>
>> Common sense about how programming languages shou
Alain Ketterlin writes:
> d[r] = [r for r in [4,5,6]]
> THe problem is that the "r" in d[r] somehow captures the value of the
> "r" in the list comprehension, and somehow kills the loop interator.
Yes, this is a well known design error in Python 2.x. The 3.x series
fixes this error but intro
On Apr 4, 2010, at 3:17 , Stephen Hansen wrote:
Where exactly does this common sense come from? A list
comprehension is
basically syntactic sugar over a for loop, and...
well, since I've been bitten by this particular wart, I was surprised
to see that the list comp didn't have it's own sco
On Sun, 04 Apr 2010 15:06:46 +0200
"Alf P. Steinbach" wrote:
> Common sense is applied first, as a heuristic. You really wouldn't want to
> drill
> down into the architect's drawings in order to get office 215 in a building.
> First you apply common sense.
Oh goodie, bad analogies. Can I play
* Ethan Furman:
Steve Howell wrote:
On Apr 3, 9:58 pm, Tim Roberts wrote:
Alain Ketterlin wrote:
I've just spent a few hours debugging code similar to this:
d = dict()
for r in [1,2,3]:
d[r] = [r for r in [4,5,6]]
print d
Yes, this has been fixed in later revisions, but I'm curious
Steve Howell wrote:
On Apr 3, 9:58 pm, Tim Roberts wrote:
Alain Ketterlin wrote:
I've just spent a few hours debugging code similar to this:
d = dict()
for r in [1,2,3]:
d[r] = [r for r in [4,5,6]]
print d
Yes, this has been fixed in later revisions, but I'm curious to know what
led
On 2010-04-03 23:30:32 -0700, Steve Howell said:
On Apr 3, 9:58 pm, Tim Roberts wrote:
Alain Ketterlin wrote:
I've just spent a few hours debugging code similar to this:
d = dict()
for r in [1,2,3]:
d[r] = [r for r in [4,5,6]]
print d
Yes, this has been fixed in later revisions, but
On Apr 3, 9:58 pm, Tim Roberts wrote:
> Alain Ketterlin wrote:
>
> >I've just spent a few hours debugging code similar to this:
>
> >d = dict()
> >for r in [1,2,3]:
> > d[r] = [r for r in [4,5,6]]
> >print d
>
> Yes, this has been fixed in later revisions, but I'm curious to know what
> led yo
Alain Ketterlin wrote:
>
>I've just spent a few hours debugging code similar to this:
>
>d = dict()
>for r in [1,2,3]:
>d[r] = [r for r in [4,5,6]]
>print d
Yes, this has been fixed in later revisions, but I'm curious to know what
led you to believe that a list comprehension created a new sco
On Sat, 03 Apr 2010 12:30:32 +0200, Alain Ketterlin wrote:
> Hi all,
>
> I've just spent a few hours debugging code similar to this:
>
> d = dict()
> for r in [1,2,3]:
> d[r] = [r for r in [4,5,6]]
> print d
This isn't directly relevant to your problem, but why use a list
comprehension in
On Sat, Apr 3, 2010 at 3:30 AM, Alain Ketterlin
wrote:
> I've just spent a few hours debugging code similar to this:
>
> d = dict()
> for r in [1,2,3]:
> d[r] = [r for r in [4,5,6]]
> print d
>
> THe problem is that the "r" in d[r] somehow captures the value of the
> "r" in the list comprehensi
Hi all,
I've just spent a few hours debugging code similar to this:
d = dict()
for r in [1,2,3]:
d[r] = [r for r in [4,5,6]]
print d
THe problem is that the "r" in d[r] somehow captures the value of the
"r" in the list comprehension, and somehow kills the loop interator. The
(unexpected) re
34 matches
Mail list logo
