Re: Odd behaviour with list comprehension

Discussion in 'Python' started by Jerry Hill, Mar 1, 2008.

  1. Jerry Hill

    Jerry Hill Guest

    On Fri, Feb 29, 2008 at 10:01 PM, Ken Pu <> wrote:
    > Is there a way for me keep the iterating variable in list
    > comprehension local to the list comprehension?


    Kind of. You can use a generator expression instead of a list
    comprehension, and those don't leak their internal variables into the
    enclosing scope:

    >>> list(x for x in range(10))

    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
    >>> x


    Traceback (most recent call last):
    File "<pyshell#2>", line 1, in <module>
    x
    NameError: name 'x' is not defined
    >>>


    You have to pass it to the list constructor to get a list out of it,
    though. For more on generator expressions see PEP 289:
    http://www.python.org/dev/peps/pep-0289/

    --
    Jerry
     
    Jerry Hill, Mar 1, 2008
    #1
    1. Advertising

  2. Jerry Hill

    Micah Cowan Guest

    "Jerry Hill" <> writes:

    > On Fri, Feb 29, 2008 at 10:01 PM, Ken Pu <> wrote:
    >> Is there a way for me keep the iterating variable in list
    >> comprehension local to the list comprehension?

    >
    > Kind of. You can use a generator expression instead of a list
    > comprehension, and those don't leak their internal variables into the
    > enclosing scope:


    Whoa, that's cool. I didn't even think to try that, just assuming it
    would do the same.

    Though now that I think about it, I don't see how it possibly could,
    since it just evaluates to an object that you could pass around, and
    return, using it the same way elsewhere.

    --
    Micah J. Cowan
    Programmer, musician, typesetting enthusiast, gamer...
    http://micah.cowan.name/
     
    Micah Cowan, Mar 1, 2008
    #2
    1. Advertising

  3. Jerry Hill

    Steve Holden Guest

    Micah Cowan wrote:
    > "Jerry Hill" <> writes:
    >
    >> On Fri, Feb 29, 2008 at 10:01 PM, Ken Pu <> wrote:
    >>> Is there a way for me keep the iterating variable in list
    >>> comprehension local to the list comprehension?

    >> Kind of. You can use a generator expression instead of a list
    >> comprehension, and those don't leak their internal variables into the
    >> enclosing scope:

    >
    > Whoa, that's cool. I didn't even think to try that, just assuming it
    > would do the same.
    >
    > Though now that I think about it, I don't see how it possibly could,
    > since it just evaluates to an object that you could pass around, and
    > return, using it the same way elsewhere.
    >

    Well, the fact that the bound variable in the list comprehension does
    indeed remain outside the construct is simply the result of an
    over-zealous wish to emulate for loop semantics. The original reasoning,
    IIRC, as that since a for loop left its bound variable at the last used
    value, so should a list comprehension.

    This was quickly recognized as a mistake, but unfortunately not quickly
    enough. As it was felt that some people might already have relied on
    that behavior, it was retained in the interests of preserving backwards
    compatibility.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
     
    Steve Holden, Mar 31, 2008
    #3
  4. Jerry Hill

    Terry Reedy Guest

    "Steve Holden" <> wrote in message
    news:fspe8a$ptq$...
    | Micah Cowan wrote:
    | > "Jerry Hill" <> writes:
    | >
    | >> On Fri, Feb 29, 2008 at 10:01 PM, Ken Pu <>
    wrote:
    | >>> Is there a way for me keep the iterating variable in list
    | >>> comprehension local to the list comprehension?
    | >> Kind of. You can use a generator expression instead of a list
    | >> comprehension, and those don't leak their internal variables into the
    | >> enclosing scope:
    | >
    | > Whoa, that's cool. I didn't even think to try that, just assuming it
    | > would do the same.
    | >
    | > Though now that I think about it, I don't see how it possibly could,
    | > since it just evaluates to an object that you could pass around, and
    | > return, using it the same way elsewhere.
    | >
    | Well, the fact that the bound variable in the list comprehension does
    | indeed remain outside the construct is simply the result of an
    | over-zealous wish to emulate for loop semantics. The original reasoning,
    | IIRC, as that since a for loop left its bound variable at the last used
    | value, so should a list comprehension.
    |
    | This was quickly recognized as a mistake, but unfortunately not quickly
    | enough. As it was felt that some people might already have relied on
    | that behavior, it was retained in the interests of preserving backwards
    | compatibility.

    But it will not be retained in 3.0, as I understand it.
    So best to not exploit the deprecated behavior.

    tjr
     
    Terry Reedy, Mar 31, 2008
    #4
  5. Jerry Hill

    Steve Holden Guest

    Terry Reedy wrote:
    > "Steve Holden" <> wrote in message

    [...]
    > | Well, the fact that the bound variable in the list comprehension does
    > | indeed remain outside the construct is simply the result of an
    > | over-zealous wish to emulate for loop semantics. The original reasoning,
    > | IIRC, as that since a for loop left its bound variable at the last used
    > | value, so should a list comprehension.
    > |
    > | This was quickly recognized as a mistake, but unfortunately not quickly
    > | enough. As it was felt that some people might already have relied on
    > | that behavior, it was retained in the interests of preserving backwards
    > | compatibility.
    >
    > But it will not be retained in 3.0, as I understand it.
    > So best to not exploit the deprecated behavior.
    >

    Correct. The compatibility break provided by 3.0 allows the developers
    to drop this historical grunge.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
     
    Steve Holden, Mar 31, 2008
    #5
    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. Shane Geiger
    Replies:
    4
    Views:
    408
    bullockbefriending bard
    Mar 25, 2007
  2. Debajit Adhikary
    Replies:
    17
    Views:
    726
    Debajit Adhikary
    Oct 18, 2007
  3. Ken Pu
    Replies:
    2
    Views:
    283
    Jeffrey Froman
    Mar 1, 2008
  4. Vedran Furac(
    Replies:
    4
    Views:
    357
    Marc 'BlackJack' Rintsch
    Dec 19, 2008
  5. Artur Siekielski
    Replies:
    6
    Views:
    303
    Terry Reedy
    May 7, 2010
Loading...

Share This Page