Amaury - I think it's generally cleaner code to write
for myObject in someList:
if myObject.fits():
process(myObject)
break
than
for myObject in someList:
if myObject.fits():
break
process(myObject)
I see from csv.py how it could simplify thing
2008/4/18, Nicholas T <[EMAIL PROTECTED]>:
> Amaury - I think it's generally cleaner code to write
> for myObject in someList:
> if myObject.fits():
>process(myObject)
> break
> than
>for myObject in someList:
> if myObject.fits():
> break
>
I like that loop variables end up still in scope, as demonstrated so
far on this list it is quite useful, but only when there is a break
somewhere. The one that confuses me, therefore, is the dummy variables
in a generator expression leaking into the scope defining that
expression. Hence:
x = 0
L
On Fri, Apr 18, 2008 at 8:29 AM, Richard Thomas
<[EMAIL PROTECTED]> wrote:
> I like that loop variables end up still in scope, as demonstrated so
> far on this list it is quite useful, but only when there is a break
> somewhere. The one that confuses me, therefore, is the dummy variables
> in a
Richard Thomas schrieb:
> I like that loop variables end up still in scope, as demonstrated so
> far on this list it is quite useful, but only when there is a break
> somewhere. The one that confuses me, therefore, is the dummy variables
> in a generator expression leaking into the scope defining t
Alex Martelli wrote:
> LCs were originally designed to leak
Well, they weren't really *designed* to leak, it was
just a side effect of the implementation.
It seems to have been decided that it was better to
keep it that way than risk breaking things that might
depend on it. Personally I would rat
2008/4/17, Guido van Rossum <[EMAIL PROTECTED]>:
> For those of us with less capable IO devices, setting the error flag
> for stdout and stderr to backslashreplace is probably the best
> solution (and it solves more problems than just repr()).
>
Some thought on Points I found while investigati
