List comprehensions appear to store their temporary result in a
variable named "_[1]" (or presumably "_[2]", "_[3]" etc for nested
comprehensions)
In other words, there are variables being put into the namespace with
illegal names (names can't contain brackets). Can't someone come up
with a better hack than this? How about using "_1", "_2", etc, or
actually making "_" a list of lists and using the real first, second,
third elements? This is an unexpected wrench in the works for people
trying to implement custom global namespaces.
Illustration:
class custom_namespace(dict):
def __getitem__(self, i):
print "GET", i
return dict.__getitem__(self, i)
eval("[x for x in range(10)]", custom_namespace()) 6 1374
Lonnie> List comprehensions appear to store their temporary result in a
Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for
Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix
it in list comprehensions. I believe at some point in the future they may
just go away or become syntactic sugar for a gen comp wrapped in a list()
call.
Skip sk**@pobox.com wrote: Lonnie> List comprehensions appear to store their temporary result in a Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix it in list comprehensions. I believe at some point in the future they may just go away or become syntactic sugar for a gen comp wrapped in a list() call.
The latter, starting in Python 3.0. It won't be fixed before Python
3.0 because it has the potential to break existing 2.x code. From PEP
289:
"""List comprehensions also "leak" their loop variable into the
surrounding scope. This will also change in Python 3.0, so that the
semantic definition of a list comprehension in Python 3.0 will be
equivalent to list(<generator expression>). Python 2.4 and beyond
should issue a deprecation warning if a list comprehension's loop
variable has the same name as a variable used in the immediately
surrounding scope."""
Source: http://www.python.org/dev/peps/pep-0289/
Also mentioned in PEP 3100.
Doesn't look like the deprecation warning was ever implemented for 2.4,
though. On my 2.4.3: def f():
[x for x in range(10)]
print x f()
9 # no warning yet..
2.5 is in alpha now, hopefully the warning will be added.
--Ben
Ben Cartwright schrieb: sk**@pobox.com wrote: Lonnie> List comprehensions appear to store their temporary result in a Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix it in list comprehensions. I believe at some point in the future they may just go away or become syntactic sugar for a gen comp wrapped in a list() call.
The latter, starting in Python 3.0. It won't be fixed before Python 3.0 because it has the potential to break existing 2.x code. From PEP 289:
That is a different beast. Lonnie is after the temporary list variables
created, with otherwise illegal names in python.
Diez sk**@pobox.com wrote: Lonnie> List comprehensions appear to store their temporary result in a Lonnie> variable named "_[1]" (or presumably "_[2]", "_[3]" etc for Lonnie> nested comprehensions)
Known issue. Fixed in generator comprehensions. Dunno about plans to fix it in list comprehensions. I believe at some point in the future they may just go away or become syntactic sugar for a gen comp wrapped in a list() call.
Point of information, would this be the interpreter putting
the result of its last calculation in _ ?
Python 2.4.2 (#1, Jan 23 2006, 21:24:54)
[GCC 3.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more
information. [2*x for x in range(5)]
[0, 2, 4, 6, 8] _[4]
8
Mel.
"Mel Wilson" <mw********@sympatico.ca> wrote in message
news:7h*******************@news20.bellglobal.com.. . Point of information, would this be the interpreter putting the result of its last calculation in _ ?
Yes, in interactive mode (but not in batch mode) it binds the valid name
'_' to the result of statement expressions. [2*x for x in range(5)] [0, 2, 4, 6, 8] _[4]
8
which here is the list.
Terry Jan Reedy
In article <ma***************************************@python. org>,
"Terry Reedy" <tj*****@udel.edu> wrote: "Mel Wilson" <mw********@sympatico.ca> wrote in message news:7h*******************@news20.bellglobal.com.. . Point of information, would this be the interpreter putting the result of its last calculation in _ ?
Yes, [ ... ]
No, actually. It's an implementation detail of list comps. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Elaine Jackson |
last post by:
List comprehensions don't work the way you intuitively expect them to work. I
realize many people have no intuitions about how list comprehensions 'should'
work, so if you recognize yourself in...
|
by: Moosebumps |
last post by:
Does anyone here find the list comprehension syntax awkward?
I like it because it is an expression rather than a series of statements,
but it is a little harder to maintain it seems.
e.g. you...
|
by: Mahesh Padmanabhan |
last post by:
Hi,
When list comprehension was added to the language, I had a lot of
trouble understanding it but now that I am familiar with it, I am not
sure how I programmed in Python without it.
Now I...
|
by: Neuruss |
last post by:
I have a doubt regarding list comprehensions:
According to Mark Lutz in his book Learning Pyhon:
"...there is currently a substantial performance advantage to the
extra complexity in this case:...
|
by: Alan McIntyre |
last post by:
Hi all,
I have a list of items that has contiguous repetitions of values, but
the number and location of the repetitions is not important, so I just
need to strip them out. For example, if my...
|
by: Mike Meyer |
last post by:
Ok, we've added list comprehensions to the language, and seen that
they were good. We've added generator expressions to the language, and
seen that they were good as well.
I'm left a bit...
|
by: Steven Bethard |
last post by:
George Sakkis wrote:
> "Steven Bethard" <steven.bethard@gmail.com> wrote:
>> Dict comprehensions were recently rejected:
>> http://www.python.org/peps/pep-0274.html
>> The reason, of course,...
|
by: Steven Bethard |
last post by:
Tom Anderson <twic@urchin.earth.li> wrote:
> Sounds good. More generally, i'd be more than happy to get rid of list
> comprehensions, letting people use list(genexp) instead. That would
>...
|
by: Heiko Wundram |
last post by:
Hi all!
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
Comments appreciated, including on the sample implementation.
===...
|
by: John Salerno |
last post by:
I posted this code last night in response to another thread, and after I
posted it I got to wondering if I had misused the list comprehension. Here's
the two examples:
Example 1:...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |