Re: [Python-Dev] Visibility scope for for/while/if statements
On Thursday 2005-09-22 20:00, Josiah Carlson wrote:
[Alexander Myodov:]
But for the performance-oriented/human-friendliness factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
C does not have pseudo-namespaces or variable encapsulation in for loops.
Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
does not rival C in the performance/friendliness realm? Who are you
trying to kid?
I think you've misunderstood Alex here; he's saying that Python
and C don't occupy the same region of the spectrum that runs
from high performance, human-unfriendly to lower performance,
human friendly. Which is correct, unlike some other things he's
said :-).
for (int i = 0; i 10; i++) works fine nowadays.
I'm sorry, but you are wrong. The C99 spec states that you must define
the type of i before using it in the loop. Maybe you are thinking of
C++, which allows such things.
No, Alex is right on this one too. Maybe you are thinking of C89,
which forbids such things.
6.8.5.3 The for statement
[#1] Except for the behavior of a continue statement in the
loop body, the statement
for ( clause-1 ; expr-2 ; expr-3 ) statement
and the sequence of statements
{
clause-1 ;
while ( expr-2 ) {
statement
expr-3 ;
}
}
are equivalent (where clause-1 can be an expression or a
declaration).123)
...
123Thus, clause-1 specifies initialization for the loop,
possibly declaring one or more variables for use in the
loop; expr-2, the controlling expression, specifies an
evaluation made before each iteration, such that
execution of the loop continues until the expression
compares equal to 0; expr-3 specifies an operation (such
as incrementing) that is performed after each iteration.
If clause-1 is a declaration, then the scope of any
variable it declares is the remainder of the declaration
and the entire loop, including the other two expressions.
(This is from a late draft of the C99 spec; I'm fairly sure
the final version is no different.)
--
g
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Andrew Koenig wrote:
Interestingly enough, not all C++ compilers (Microsoft) hid variables
created in for loops
(http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2).
That's because the C++ spec changed during standardization, when the
standards committee realized the original idea was a mistake.
One of the convincing cases:
if (x)
for (int i = 0; i != 10; ++i) { }
Is I in scope after the if statement? If so, what value does it have if x
is false? If not, then apparently the subject of an if statement is a
scope...so why can't I write this?
if (x)
int i = 42;
and have i go out of scope?
The difference is that C++ uses {} to delineate a new scope, whereas Python
uses only def statements.
The behaviour in C++ and C99 can indeed be quite handy, and aligns perfectly
with the static type system of those languages. Importantly, creating a new
scope is cheap - it's just a matter of moving the stack pointer around a bit
(and maybe invoking some destructors that would have been invoked eventually
anyway).
Python, however, uses a dynamic name binding system and scopes are expensive
because they require setting up all of the machinery to support nested
visibility. That is, additional inline scoping would add significant *runtime*
overhead. So a different design choice was made in Python, but that choice is
still internally consistent.
Using the above example:
if x:
for i in range(10): pass
print i
if x:
i = 42
print i
What happens on the 'print i' line in Python if 'x' is false? Easy: attempting
to access 'i' will result in UnboundLocalError being raised at runtime, just
as it would if the 'print i' line was *before* the if statement. That's
because the name 'i' *is* in scope - it just hasn't been bound to anything yet.
As Guido has said, this is really a discussion for c.l.p. Even before taking
it there, however, I suggest reviewing the c.l.p discussion from January
regarding the idea of 'statement local namespaces' [1] (and also checking the
archives to see if the discussion has moved on since then, as I haven't been
following c.l.p. for a good long while).
Regards,
Nick.
[1] http://mail.python.org/pipermail/python-list/2005-January/259556.html
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Nick Coghlan wrote: Python, however, uses a dynamic name binding system and scopes are expensive because they require setting up all of the machinery to support nested visibility. Scopes within a function needn't be anywhere near as expensive as scopes for nested functions are. The compiler can just allocate all the locals that are going to be needed on entry to the function, and keep track of which ones are visible. The only runtime overhead would be unbinding locals as they go out of scope, if that were considered necessary or desirable. The main problem is Python's lack of declarations, which means that nested locals could only be used in places where it's clear that a new variable is being introduced, such as for loops, LCs, etc. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Alexander Myodov [EMAIL PROTECTED] wrote:
Hello,
Don't want to be importunate annoyingly asking the things probably
trivial for experienced community, but need to ask it anyway, after
spending about two hours trying to find well-camouflaged error caused
by it.
In the future you should test your assumptions before writing software
with them.
Why the variables defined inside for/while/if statements
(including loop variables for for) are visible outside this scope?
if and while statements don't define variables, so they can't expose
them later in the scope.
In regards to 'for' loops, they have always done that, there is code
that relies on that behavior, and changing behavior would unnecessarily
break code.
As for list comprehensions, they were literally meant to be a
completely equivalent translation of a set of for loops. That is:
x = []
for i in foo:
if f(i):
x.append(i)
could be translated into
x = [i for i in foo if f(i)]
and one would get the exact same side effects, including the 'leaking'
of the most recently bound i into the local scope. The leakage was not
accidental.
Yes, I am aware of one use case for this... er, feature.
It could be useful to remember the last item of the loop after the loop
is done... sometimes. But what is it for in other cases, except
confusing the programmer?
There is a great reason: there generally exists two namespaces in Python,
locals and globals (you can get a representation of of locals by using
locals() (your changes to the dictionary won't change the local scope),
and get a reference to the globals dictionary by globals()...there is
also __builtins__, but you shouldn't be playing with that unless you
know what you are doing). These namespaces offer you access to other
namespaces (class, module, etc.).
In most cases (the body of a function or method), the local scope is
defined as an array with offset lookups:
def foo(n):
... n + 1
...
dis.dis(foo)
2 0 LOAD_FAST0 (n) - look at this opcode
3 LOAD_CONST 1 (1)
6 BINARY_ADD
7 POP_TOP
8 LOAD_CONST 0 (None)
11 RETURN_VALUE
This results in the bytecode to be executed being significantly faster
than if it were to reference a dictionary (like globals).
dis.dis(compile('n+1', '_', 'single'))
1 0 LOAD_NAME0 (n) - compare with this
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 PRINT_EXPR
8 LOAD_CONST 1 (None)
11 RETURN_VALUE
Since the LOAD_NAME opcode does a dictionary lookup, it is necessarily
slower than an array + offset lookup.
Further, you should clarify what you would want this mythical non-leaky
for loop to do in various cases. What would happen in the following
case?
i = None
for i in ...:
...
print i
... assuming that the loop executed more than once? Would you always
get 'None' printed, or would you get the content of the last variable?
What about:
x = None
for i in ...:
x = f(i)
...
print x
Would 'x' be kept after the loop finished executing?
I would imagine in your current code you are running something like
this:
i = #some important value
... #many lines of code
for i in ...:
...
#you access the 'i' you bound a long time ago
In this case, you are making a common new programmer mistake by using
the same variable name for two disparate concepts. If the 'i' that was
initially bound was important through the lifetime of the scope, you
should have named it differently than the 'i' that was merely a loop
variable.
I will also point out that in general, not leaking/exposing/etc. such
variables would necessarily slow down Python. Why? Because it would
necessitate nesting the concept of pseudo-namespaces. Now, when a
function is compiled, nearly every local name is known, and they can be
made fast (in the Python sense). If one were to nest pseudo namespaces,
one would necessarily have another namespace lookup for every nested for
loop. More specifically, accessing 'foo' in these three different
nestings would take different amounts of time.
for i in xrange(10):
x = foo
for i in xrange(10):
for j in xrange(10):
x = foo
for i in xrange(10):
for j in xrange(10):
for k in xrange(10):
x = foo
And in the case that you do or don't want 'x' to 'leak' into the
surrounding scope, you either take the speed hit again, or break quite a
bit of code and be inconsistant.
Or maybe can someone hint me whether I can somehow switch the behaviour on
source-level to avoid keeping the variables outside the statements?
No.
Something like Perlish import strict? I couldn't find it myself.
While global change of Python to the variables local to statements and
list comprehension could
Re: [Python-Dev] Visibility scope for for/while/if statements
Hello Josiah,
Why the variables defined inside for/while/if statements
(including loop variables for for) are visible outside this scope?
JC if and while statements don't define variables, so they can't expose
JC them later in the scope.
They don't. They just leak internal ones:
i = 0
while i != 1:
i += 1
j = 5
print j
JC In regards to 'for' loops, they have always done that, there is code
JC that relies on that behavior, and changing behavior would unnecessarily
JC break code.
I mentioned it below: while unconditional changing the behaviour will
definitely break a lot, something like import strict would help
those ones who rate such behaviour enough error-prone to
reconsider proceeding using Python at all.
JC Further, you should clarify what you would want this mythical non-leaky
JC for loop to do in various cases. What would happen in the following
JC case?
JC i = None
JC for i in ...:
JC ...
JC print i
JC ... assuming that the loop executed more than once? Would you always
JC get 'None' printed, or would you get the content of the last variable?
As for me (if my humble opinion is useful for you), the best would be
to 1. assume that a loop variable is always newly-declared for this
loop, 2. all variables first declared inside the loop are local to this
loop.
Thus, your example falls to case 1: i variable is newly declared for
this loop. Well, we don't reuse old value of i to start the iteration
from a particular place, like below?
i = 5
for i in [3,4,5,6,7]:
print i,
More general, the variables could be assumed local only to the *same
or higher* indentation level.
JC What about:
JC x = None
JC for i in ...:
JC x = f(i)
JC ...
JC print x
JC Would 'x' be kept after the loop finished executing?
case 2: x variable is declared already. And if there is no
x = None line, it should tell name 'x' is not defined. Unless we
are prone to funny uncertainly defined cases, if some variable is
defined inside an in in the loop.
JC I would imagine in your current code you are running something like
JC this:
JC i = #some important value
JC ... #many lines of code
JC for i in ...:
JC ...
JC #you access the 'i' you bound a long time ago
JC In this case, you are making a common new programmer mistake by using
JC the same variable name for two disparate concepts.
Nah, here is my error-case:
I made several loops, one by one, using the i variable for looping.
Then in the latest loop I changed the i name to more meaningful
imsi name in the for declaration and whenever I found inside the loop.
As I use i name *for loops exclusively*, I didn't wittingly reuse the
same name for different purposes. The problem was that I missed one
occurance of i variable inside the loop code, so it gained the same
value (from the completion of previous loop) throughout all the imsi
loop. And the interpreter didn't notice me that I am using the
undefined variable (since it is considered defined in Python), as
accustomed from other languages. That's my sorrowful story.
JC If the 'i' that was
JC initially bound was important through the lifetime of the scope, you
JC should have named it differently than the 'i' that was merely a loop
JC variable.
I'm pretty happy that I didn't ever made a list comprehension with i
variable inside the loop over i variable. While I wasn't aware of
these side-effects, it would be even harder spottable. Now I'll look
more carefully at copy-pasting list comprehensions, in every case
examining all of the lower-indent variables for not to clash.
JC I will also point out that in general, not leaking/exposing/etc. such
JC variables would necessarily slow down Python. Why?
I agree, this is one of obvious advantages of absence of
pseudo-namespaces (wasting the resources to allocation and removal of
variables, etc). Though in case of presence of pseudo-namespaces, it
an easily be emulated by initializing the variable first-time on the
highest-level of indentation.
But for the performance-oriented/human-friendliness factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
JC Python semantics seem to have been following the rule of we are all
JC adults here.
I always believed that the programming language (as any computer
program) should slave to the human, rather than a human should slave
to the program.
JC Generally though, Python follows a common C semantic of variable leakage.
JC C Code:
JC int i; // required in some versions of C
JC for (i=0;i10;i++) {
JC ...
JC }
for (int i = 0; i 10; i++) works fine nowadays.
JC Again: test your assumptions. If your untested assumptions are wrong,
JC don't complain that the language is broken.
In my case, as I explained already, it was not a assumption but an
uncatched mistype, which is usually catched in other languages due to
the presence of pseudo-namespaces (and in other languages I even
accustomed to enforce the
Re: [Python-Dev] Visibility scope for for/while/if statements
Alexander Myodov wrote: Thus, your example falls to case 1: i variable is newly declared for this loop. Well, we don't reuse old value of i to start the iteration from a particular place, like below? i = 5 for i in [3,4,5,6,7]: print i, More general, the variables could be assumed local only to the *same or higher* indentation level. So (since you're talking about if as well as for and while) you're suggesting that x = 0 if foo(): x = 1 else: x = 2 should always leave x == 0? Or that the same bit of code, without the first line, should always leave x undefined? JC Python semantics seem to have been following the rule of we are all JC adults here. I always believed that the programming language (as any computer program) should slave to the human, rather than a human should slave to the program. Right. And some of us humans *don't want* the change you're proposing. For what it's worth, I think it might well have been better if for and comprehensions had made their loop variables block-local; especially comprehensions. But making every for/while/if introduce a new level of scoping would be horrible. Perhaps you think it's what you want, but I think if you tried it for a month then you'd change your mind. -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Alexander Myodov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Why the variables defined inside for/while/if statements (including loop variables for for) are visible outside this scope? Questions about why Python is the way it is belong on comp.lang.python, the general Python mailing list, or gmane.comp.python.general (they are all gatewayed to each other). Moreover, they are likely to have been asked, answered, and discussed previously, with the answers possibly discoverable thru Google search of the c.l.p archives. This one certainly has been. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Alexander Myodov [EMAIL PROTECTED] wrote:
[snip Alexander Myodov complaining about how Python works]
i = 0
while i != 1:
i += 1
j = 5
print j
Maybe you don't realize this, but C's while also 'leaks' internal
variables...
int i = 0, j;
while (i != 1) {
i++;
j = 5;
}
printf(%i %i\n, i, j);
If you haven't yet found a good use for such 'leakage', you should spend
more time programming and less time talking; you would find (quite
readily) that such 'leaking' is quite beneficial.
I made several loops, one by one, using the i variable for looping.
Then in the latest loop I changed the i name to more meaningful
imsi name in the for declaration and whenever I found inside the loop.
As I use i name *for loops exclusively*, I didn't wittingly reuse the
same name for different purposes. The problem was that I missed one
occurance of i variable inside the loop code, so it gained the same
value (from the completion of previous loop) throughout all the imsi
loop. And the interpreter didn't notice me that I am using the
undefined variable (since it is considered defined in Python), as
accustomed from other languages. That's my sorrowful story.
So you mistyped something. I'm crying for you, really I am.
But for the performance-oriented/human-friendliness factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
C does not have pseudo-namespaces or variable encapsulation in for loops.
Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
does not rival C in the performance/friendliness realm? Who are you
trying to kid? There is a reason why high school teachers are teaching
kids Python instead of Pascal, Java, etc., it's because it is easier to
learn and use. On the performance realm, of course Python is beat out
by low-level languages; it was never meant to compete with them. Python
does what it can for speed when such speed does not affect the usability
of the language. What you are proposing both would reduce speed and
usability, which suggests that it wasn't a good idea in the first place.
JC Python semantics seem to have been following the rule of we are all
JC adults here.
I always believed that the programming language (as any computer
program) should slave to the human, rather than a human should slave
to the program.
Your beliefs were unfounded. If you look at every programming language,
there are specific semantics and syntax for all of them. If you fail to
use and/or understand them, the langauge will not be your 'slave'; it
will not run correctly, if at all.
for (int i = 0; i 10; i++) works fine nowadays.
I'm sorry, but you are wrong. The C99 spec states that you must define
the type of i before using it in the loop. Maybe you are thinking of
C++, which allows such things.
JC Also: python-dev is a mailing list for the development /of/ Python.
JC Being that your questions as of late have been in the realm of why does
JC or doesn't Python do this?, you should go to python-list (or the
JC equivalent comp.lang.python newsgroup) for answers to questions
JC regarding current Python behavior, and why Python did or didn't do
JC something in its past.
I'm sorry for wasting the time of developers. For for/while/if
statements, I just had an idea which (I believed) could be useful for
many peoples,
Test your ideas on comp.lang.python first, when more than a handful of
people agree with you, come back.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Hello Josiah,
i = 0
while i != 1:
i += 1
j = 5
print j
JC Maybe you don't realize this, but C's while also 'leaks' internal
JC variables...
JC int i = 0, j;
JC while (i != 1) {
JC i++;
JC j = 5;
JC }
JC printf(%i %i\n, i, j);
Yeah, it may *leak* it in your example. But the advantage is that it
may *not leak* as well:
for (int i = 0; i = 5; i++) { int j = 5; }
printf (%i\n, j); // Won't be even compiled
Or in our while case:
int i = 0;
while (i != 1) {
i++;
int j = 5;
}
printf(%i %i\n, i, j);
JC If you haven't yet found a good use for such 'leakage', you should spend
JC more time programming and less time talking; you would find (quite
JC readily) that such 'leaking' is quite beneficial.
I see such usages and realize the possible gains from it. But for
about five years of software development in a bunch of programming
languages, I've found good uses of non-leaking variables *as well*. Up
to the level of manually enclosing the temporary variables used only
once:
...
int i = input();
int result;
{
int j = f1(i);
int k = f2(i, j);
result = f3(i, j, k);
} // Now j and k are dead
...
accustomed from other languages. That's my sorrowful story.
JC So you mistyped something. I'm crying for you, really I am.
Yeah, I did. Just forgot removing the usage / renaming of variable neved
initialized (I thought) before. And my error was that I relied upon
the interpreter to catch it, mistakenly assuming the locality of
variables inside loops as a consistency with other common languages.
Mea culpa, without any jeers. The only reason why I was wrote my email
was to get the understanding of community assessment of such
behaviour, and/or probable workarounds. No blame against Python - it's
great even with this unusualty.
But for the performance-oriented/human-friendliness factor, Python
is anyway not a rival to C and similar lowlevellers. C has
pseudo-namespaces, though.
JC C does not have pseudo-namespaces or variable encapsulation in for loops.
Neither
for (int i = 0; i = 5; i++) { int j = 5; }
printf (%i\n, i);
nor
for (int i = 0; i = 5; i++) { int j = 5; }
printf (%i\n, j);
gets compiled though with gcc -std=c99. That is, each loop
introduces a new scoping level.
JC Ah hah hah! Look ladies and gentlemen, I caught myself a troll! Python
JC does not rival C in the performance/friendliness realm? Who are you
JC trying to kid? There is a reason why high school teachers are teaching
JC kids Python instead of Pascal, Java, etc., it's because it is easier to
JC learn and use.
Ohh, my slip made me considered a troll... I meant only that Python
does not rival C in such area as performance by all means, even with
decrease of friendliness (but the overall performance is indeed good,
I've seen even the VoIP solution written purely on on Python). And I
believe noone of Python developers want it to be rival.
JC What you are proposing both would reduce speed and
JC usability, which suggests that it wasn't a good idea in the first place.
Yes, it lacks performance, but I still believe that an opportunity to close the
visibility of variables (*opportunity* rather than *behaviour
change*!) is better in terms of friendliness rather than lack of it.
Just because it offers the alternatives. Because C-style closed
visibility can emulate the variable lack, but not vice versa.
At least one voice here (of Gareth McCaughan) is not-strictly-against
it. So I cannot agree that such *option* can reduce usability.
for (int i = 0; i 10; i++) works fine nowadays.
JC I'm sorry, but you are wrong. The C99 spec states that you must define
JC the type of i before using it in the loop. Maybe you are thinking of
JC C++, which allows such things.
gcc -std=c99 compiles the line for (int i = 0; i = 5; i++);
perfectly. Along with another sample mentioned above .
To this day, I relied upon gcc in terms of standards compatibility...
JC Tes your ideas on comp.lang.python first, when more than a handful of
JC people agree with you, come back.
Ok. Next time I shall be more careful. Sorry again, and thanks for
your time. And thanks for more-or-less patient answers.
--
With best regards,
Alexander mailto:[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Alexander Myodov [EMAIL PROTECTED] wrote: for (int i = 0; i 10; i++) works fine nowadays. JC I'm sorry, but you are wrong. The C99 spec states that you must define JC the type of i before using it in the loop. Maybe you are thinking of JC C++, which allows such things. gcc -std=c99 compiles the line for (int i = 0; i = 5; i++); perfectly. Along with another sample mentioned above . To this day, I relied upon gcc in terms of standards compatibility... I misread the error message from my compiler. It /only/ works in C99 mode. Previous C standards (which CPython itself conforms to) did not allow such things. Interestingly enough, not all C++ compilers (Microsoft) hid variables created in for loops (http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Please end this thread. It belongs in c.l.py. Nothing's going to change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
Josiah Carlson wrote: As for list comprehensions, they were literally meant to be a completely equivalent translation of a set of for loops. I don't think that's quite true. I doubt whether anyone really thought about the issue when LCs were first being discussed. I didn't, but if I had, I wouldn't have considered the variable-leaking as being something that it was necessary to preserve, because the only use case for it is something you can't do with an LC anyway. The reasons for the variable-leaking being preserved are (1) it fell out of the implementation and (2) it makes the documentation slightly simpler, since LCs can be described fully and accurately in terms of translation to for-loops. Whether those are *good* reasons or not is debatable. In Py3k it's possible that this will be resolved by making for-loop variables local to the loop as well. Or maybe not. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visibility scope for for/while/if statements
On 9/22/05, Greg Ewing [EMAIL PROTECTED] wrote: Josiah Carlson wrote: As for list comprehensions, they were literally meant to be a completely equivalent translation of a set of for loops. I don't think that's quite true. I doubt whether anyone really thought about the issue when LCs were first being discussed. I didn't, but if I had, I wouldn't have considered the variable-leaking as being something that it was necessary to preserve, because the only use case for it is something you can't do with an LC anyway. The reasons for the variable-leaking being preserved are (1) it fell out of the implementation and (2) it makes the documentation slightly simpler, since LCs can be described fully and accurately in terms of translation to for-loops. Whether those are *good* reasons or not is debatable. It was the cheapest implementation; it was known at the time that it wasn't ideal. I'd like to fix this in 3.0, so that LC's are just a special case of GE's. In Py3k it's possible that this will be resolved by making for-loop variables local to the loop as well. Or maybe not. Definitely not. There are lots of uses for the loop control variable after break. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
