list comprehensions put non-names into namespaces!

Discussion in 'Python' started by Lonnie Princehouse, May 25, 2006.

  1. 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())
    Lonnie Princehouse, May 25, 2006
    #1
    1. Advertising

  2. Lonnie Princehouse

    Guest

    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
    , May 25, 2006
    #2
    1. Advertising

  3. 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, May 26, 2006
    #3
  4. Ben Cartwright schrieb:
    > 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
    Diez B. Roggisch, May 26, 2006
    #4
  5. Lonnie Princehouse

    Mel Wilson Guest

    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, May 26, 2006
    #5
  6. Lonnie Princehouse

    Terry Reedy Guest

    "Mel Wilson" <> wrote in message
    news:7hBdg.2071$...
    > 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
    Terry Reedy, May 26, 2006
    #6
  7. Lonnie Princehouse

    Just Guest

    In article <>,
    "Terry Reedy" <> wrote:

    > "Mel Wilson" <> wrote in message
    > news:7hBdg.2071$...
    > > 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.
    Just, May 26, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. seguso
    Replies:
    9
    Views:
    377
    seguso
    Dec 22, 2004
  2. Dave Kuhlman

    Re: Style in list comprehensions

    Dave Kuhlman, Aug 15, 2003, in forum: Python
    Replies:
    1
    Views:
    323
    Alex Martelli
    Aug 16, 2003
  3. Frank Millman

    Simple db using list comprehensions

    Frank Millman, Apr 5, 2004, in forum: Python
    Replies:
    1
    Views:
    277
    Paddy McCarthy
    Apr 16, 2004
  4. Steven Bethard
    Replies:
    7
    Views:
    388
    Rocco Moretti
    Jan 20, 2006
  5. Replies:
    4
    Views:
    486
    Joe Kesselman
    Feb 25, 2007
Loading...

Share This Page