The variable used for iteration in list comprehensions
is still in scope after the list comprehension. 

>>>foo = [1, 2, 3]
>>>bar = [dummy + 1 for dummy in foo]
>>>dummy
3

Expected result: NameError: name 'dummy' is not defined

Logged In: YES 
user_id=80475

This is not a bug.  It is behaving as designed.  The thought
was to emulate the behavior of an equivalent for-loop.

In future versions of Python, Guido would like to change the
design to hide the induction variable.  So, someday, you'll
get your wish.

Logged In: YES 
user_id=750513

Seemingly (according to:
http://docs.python.org/ref/lists.html) this is indeed a bug
that should be fixed.

Logged In: YES 
user_id=341410

"this behavior is deprecated, and relying on it will not
work once this bug is fixed in a future release"

As we have not yet reached the future release in which this
will happen, and the 'bug' is both known and documented, it
will be 'fixed' when it is fixed.  The reason that it has
not yet been 'fixed' is because there is a nontrivial amount
of code that would break if it was.

I personally would call it a deprecated 'feature'.  Then
again, I use it more often than I should.

Logged In: YES 
user_id=193957

Either this is a bug that should be fixed, or the
documentation that says it is a bug should be fixed
(http://www.python.org/doc/current/ref/lists.html#foot4519).

That fact that an ordinary for loop leaks the control
variables into the containing scope may be a design feature,
but the same behavior for list comprehensions can hardly be
called a design feature. At least not one that is
reasonable. I would rather call it a bug. It definitely
contradicts the principle of least surprise.

The resolution on this bug reads, "In future versions of Python, Guido
would like to change the design to hide the induction variable.  So,
someday, you'll get your wish."

Can this bug be re-opened and the wart removed in 3.0?

It's already been implemented for Py3.0.

Wonderful!