On Mon, Oct 20, 2003, Guido van Rossum wrote:
?!?! When listcomps were introduced, you were strongly against any changes that would make it difficult to switch back and forth between a listcomp and its corresponding equivalent for loop. Are you changing your position or are you suggesting that for loops should grow private names? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
I don't recall what I said then. Did I say it was a feature that L = [x for x in R] print x would print the last item of R?
Are you changing your position or are you suggesting that for loops should grow private names?
No, only list comps. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Oct 20, 2003, Guido van Rossum wrote:
What I remember you saying was that it was an unfortunate but necessary consequence so that it would work the same as L = [] for x in R: L.append(x) print x You didn't want to have different semantics for two such similar constructs ("there's only one way"). You also didn't want to push a stack frame for listcomps. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
Then I guess I *have* changed my mind. I guess I didn't think of the renaming solution way back when. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 2003-10-20 at 14:08, Guido van Rossum wrote:
Not to make a big deal out of it, but I just checked on the first report of this problem that I remember. David Beazley reported this problem on python-dev a couple of years ago and suggested the renaming solution. http://mail.python.org/pipermail/python-dev/2001-May/015089.html I'm sure we talked about the problem, but since I was talking I probably said something about a nested scopes solution <0.3 wink>. In that thread, Tim did some effective channeling and said the day you approved a solution based on lambda was the day you'd kill us all. Jeremy
Tim did some effective channeling and said the day you approved a solution based on lambda was the day you'd kill us all.
Aargh! You'er on to my evil plan! :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
>> ?!?! When listcomps were introduced, you were strongly against any >> changes that would make it difficult to switch back and forth between >> a listcomp and its corresponding equivalent for loop. Guido> I don't recall what I said then. Did I say it was a feature that Guido> L = [x for x in R] Guido> print x Guido> would print the last item of R? I suspect the lack of a PEP at the time list comprehensions were added to the language allowed this to slip through. PEP 202 was mostly written after list comprehensions were checked into CVS I think (opened 2000-07-13, marked final 2001-08-14, yes 2001!). At just 84 lines it's one of the shortest PEPs. The patch I opened on SF (#400654, opened 2000-06-28, closed 2000-08-14) was essentially Greg Ewing's experimental patch, which relied heavily on the existing for loop code generation. Had there been a PEP with the usual fanfare, I suspect we'd have caught (or at least considered) variable leakage, and perhaps suppressed it. I don't recall the topic ever coming up until after list comps were part of the language. It certainly seems to be the most controversial aspect, after one accepts the idea of adding them to the language. Missing such an obvious point of contention is perhaps one of the strongest arguments for the current PEP process. Skip
On Tue, Oct 21, 2003 at 12:41:00PM +0100, Michael Hudson wrote:
Not when x is properly initialized. Anyway, this is no different from the problem of: for x in R: ... print x In any case, are there plans to also have the compiler emit warnings about potential reliance on this feature? Jp
Jp Calderone <exarkun@intarweb.us> writes:
Obviously.
Well, yes. I still think it's dubious code.
In any case, are there plans to also have the compiler emit warnings about potential reliance on this feature?
I would hope that we wouldn't make changes without emitting such a warning. I'm not sure how hard it would be to implement, tho'. (It would be /nice/ to implement a warning whenever there's a possibility of the UnboundLocalError exception, but that *definitely* requires control flow analysis and that is *definitely* a heap of work, unless the ast-branch gets some attention). Cheers, mwh -- We did requirements and task analysis, iterative design, and user testing. You'd almost think programming languages were an interface between people and computers. -- Steven Pemberton (one of the designers of Python's direct ancestor ABC)
Warning about what? I have no intent to make the example quoted above illegal; a regular for loop control variable's scope will extend beyond the loop. It's only list comprehensions where I plan to remove x from the scope after the comprehension is finished. Do you need a warning for that change too? Code that relies on it is pretty sick IMO. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Oct 21, 2003 at 09:56:31AM -0700, Guido van Rossum wrote:
Sorry, my ordering could have been a little more clear. I only meant a warning for the list comprehension case.
I agree, and I try never to write such code. But having Python point out any places I foolishly did so makes the job of fixing any bugs this change introduces into my code that much easier. It also serves to point out to people who *don't* realize how sick this construct is that a potentially large chunk of their software will break in Python X.Y (3.0?), where it will break, and why it will break. Jp
On Tue, Oct 21, 2003, Guido van Rossum wrote:
Yes, it's sick, but since you made clear previously that listcomps semantics equivalent to the corresponding for loop, I wouldn't be surprised to discover that someone converted a for loop to a listcomp without fixing that sickness. So yes, it needs a warning. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
OK, fair enough. Someone update the doc bug report for this. Initially, we're just going to document it as deprecated behavior (or maybe "despised" behavior :-). --Guido van Rossum (home page: http://www.python.org/~guido/)
"Michael Hudson" <mwh@python.net> wrote in message news:2mad7uq0mr.fsf@starship.python.net...
Someone more-or-less did -- in the tutorial. See bottom below.
A problem with such code irrespective of anything else is that it fails when R is empty.
Same would be true of for loops, except that typical after-for usage, such as searching for item in list, has else clause to set control variable to default in 'not found' cases, which include empty lists. The Ref Manual currently says nothing about leakage or overwriting. That should make leakage fair game for plugging. On the other hand, Tutorial 5.1.4 List Comprehensions says: ''' To make list comprehensions match the behavior of for loops, assignments to the loop variable remain visible outside of the comprehension:
Terry J. Reedy
Oh bah!
The regular for loop won't change.
The Ref Manual currently says nothing about leakage or overwriting. That should make leakage fair game for plugging.
Unfortunately the Ref Manual is notoriously incomplete.
Sigh. What a bummer to put this in a tutorial. :-( But it won't stop me from deprecating the feature. --Guido van Rossum (home page: http://www.python.org/~guido/)
I don't recall what I said then. Did I say it was a feature that L = [x for x in R] print x would print the last item of R?
Are you changing your position or are you suggesting that for loops should grow private names?
No, only list comps. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Oct 20, 2003, Guido van Rossum wrote:
What I remember you saying was that it was an unfortunate but necessary consequence so that it would work the same as L = [] for x in R: L.append(x) print x You didn't want to have different semantics for two such similar constructs ("there's only one way"). You also didn't want to push a stack frame for listcomps. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
Then I guess I *have* changed my mind. I guess I didn't think of the renaming solution way back when. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 2003-10-20 at 14:08, Guido van Rossum wrote:
Not to make a big deal out of it, but I just checked on the first report of this problem that I remember. David Beazley reported this problem on python-dev a couple of years ago and suggested the renaming solution. http://mail.python.org/pipermail/python-dev/2001-May/015089.html I'm sure we talked about the problem, but since I was talking I probably said something about a nested scopes solution <0.3 wink>. In that thread, Tim did some effective channeling and said the day you approved a solution based on lambda was the day you'd kill us all. Jeremy
Tim did some effective channeling and said the day you approved a solution based on lambda was the day you'd kill us all.
Aargh! You'er on to my evil plan! :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
>> ?!?! When listcomps were introduced, you were strongly against any >> changes that would make it difficult to switch back and forth between >> a listcomp and its corresponding equivalent for loop. Guido> I don't recall what I said then. Did I say it was a feature that Guido> L = [x for x in R] Guido> print x Guido> would print the last item of R? I suspect the lack of a PEP at the time list comprehensions were added to the language allowed this to slip through. PEP 202 was mostly written after list comprehensions were checked into CVS I think (opened 2000-07-13, marked final 2001-08-14, yes 2001!). At just 84 lines it's one of the shortest PEPs. The patch I opened on SF (#400654, opened 2000-06-28, closed 2000-08-14) was essentially Greg Ewing's experimental patch, which relied heavily on the existing for loop code generation. Had there been a PEP with the usual fanfare, I suspect we'd have caught (or at least considered) variable leakage, and perhaps suppressed it. I don't recall the topic ever coming up until after list comps were part of the language. It certainly seems to be the most controversial aspect, after one accepts the idea of adding them to the language. Missing such an obvious point of contention is perhaps one of the strongest arguments for the current PEP process. Skip
On Tue, Oct 21, 2003 at 12:41:00PM +0100, Michael Hudson wrote:
Not when x is properly initialized. Anyway, this is no different from the problem of: for x in R: ... print x In any case, are there plans to also have the compiler emit warnings about potential reliance on this feature? Jp
Jp Calderone <exarkun@intarweb.us> writes:
Obviously.
Well, yes. I still think it's dubious code.
In any case, are there plans to also have the compiler emit warnings about potential reliance on this feature?
I would hope that we wouldn't make changes without emitting such a warning. I'm not sure how hard it would be to implement, tho'. (It would be /nice/ to implement a warning whenever there's a possibility of the UnboundLocalError exception, but that *definitely* requires control flow analysis and that is *definitely* a heap of work, unless the ast-branch gets some attention). Cheers, mwh -- We did requirements and task analysis, iterative design, and user testing. You'd almost think programming languages were an interface between people and computers. -- Steven Pemberton (one of the designers of Python's direct ancestor ABC)
Warning about what? I have no intent to make the example quoted above illegal; a regular for loop control variable's scope will extend beyond the loop. It's only list comprehensions where I plan to remove x from the scope after the comprehension is finished. Do you need a warning for that change too? Code that relies on it is pretty sick IMO. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Oct 21, 2003 at 09:56:31AM -0700, Guido van Rossum wrote:
Sorry, my ordering could have been a little more clear. I only meant a warning for the list comprehension case.
I agree, and I try never to write such code. But having Python point out any places I foolishly did so makes the job of fixing any bugs this change introduces into my code that much easier. It also serves to point out to people who *don't* realize how sick this construct is that a potentially large chunk of their software will break in Python X.Y (3.0?), where it will break, and why it will break. Jp
On Tue, Oct 21, 2003, Guido van Rossum wrote:
Yes, it's sick, but since you made clear previously that listcomps semantics equivalent to the corresponding for loop, I wouldn't be surprised to discover that someone converted a for loop to a listcomp without fixing that sickness. So yes, it needs a warning. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
OK, fair enough. Someone update the doc bug report for this. Initially, we're just going to document it as deprecated behavior (or maybe "despised" behavior :-). --Guido van Rossum (home page: http://www.python.org/~guido/)
"Michael Hudson" <mwh@python.net> wrote in message news:2mad7uq0mr.fsf@starship.python.net...
Someone more-or-less did -- in the tutorial. See bottom below.
A problem with such code irrespective of anything else is that it fails when R is empty.
Same would be true of for loops, except that typical after-for usage, such as searching for item in list, has else clause to set control variable to default in 'not found' cases, which include empty lists. The Ref Manual currently says nothing about leakage or overwriting. That should make leakage fair game for plugging. On the other hand, Tutorial 5.1.4 List Comprehensions says: ''' To make list comprehensions match the behavior of for loops, assignments to the loop variable remain visible outside of the comprehension:
Terry J. Reedy
Oh bah!
The regular for loop won't change.
The Ref Manual currently says nothing about leakage or overwriting. That should make leakage fair game for plugging.
Unfortunately the Ref Manual is notoriously incomplete.
Sigh. What a bummer to put this in a tutorial. :-( But it won't stop me from deprecating the feature. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (7)
-
Aahz -
Guido van Rossum -
Jeremy Hylton -
Jp Calderone -
Michael Hudson -
Skip Montanaro -
Terry Reedy