Re: Local variable definition in Python list comprehension

On Thu, Sep 1, 2022 at 9:16 AM Chris Angelico wrote: > On Fri, 2 Sept 2022 at 02:10, James Tsai wrote: > > > > Hello, > > > > I find it very useful if I am allowed to define new local variables in a > list comprehension. For example, I wish to have something like

Re: Local variable definition in Python list comprehension

ample where you needed to > write a series of statements or loops and (b) a corresponding example of > how you would have preferred to have written that code, possibly > inventing some syntax or misusing ":=" as if it workeed they way you'd > like it to work? > >

Re: Local variable definition in Python list comprehension

ote: > > > > 在 2022年9月1日星期四 UTC+2 18:34:36， 写道： > > > On 9/1/22, James Tsai wrote: > > > > > > > > I find it very useful if I am allowed to define new local variables > in a > > > > list comprehension. For example, I wish to have something l

Re: Local variable definition in Python list comprehension

On 02Sep2022 07:01, Chris Angelico wrote: >On Fri, 2 Sept 2022 at 06:55, James Tsai wrote: >> No but very often when I have written a neat list/dict/set >> comprehension, I find it very necessary >> to define local variable(s) to make it more clear and concise. Otherwise I >> have to break it

Re: Local variable definition in Python list comprehension

On 2022-09-01 13:33:16 -0700, James Tsai wrote: > 在 2022年9月1日星期四 UTC+2 18:34:36， 写道： > > On 9/1/22, James Tsai wrote: > > > > > > I find it very useful if I am allowed to define new local variables in a > > > list comprehension. For example, I wish to have

Re: Local variable definition in Python list comprehension

On Fri, 2 Sept 2022 at 06:55, James Tsai wrote: > > 在 2022年9月1日星期四 UTC+2 18:34:36， 写道： > > On 9/1/22, James Tsai wrote: > > > > > > I find it very useful if I am allowed to define new local variables in a > > > list comprehension. For example, I wish to

Re: Local variable definition in Python list comprehension

在 2022年9月1日星期四 UTC+2 18:16:03， 写道： > On Fri, 2 Sept 2022 at 02:10, James Tsai wrote: > > > > Hello, > > > > I find it very useful if I am allowed to define new local variables in a > > list comprehension. For example, I wish to have something like > >

Re: Local variable definition in Python list comprehension

在 2022年9月1日星期四 UTC+2 18:34:36， 写道： > On 9/1/22, James Tsai wrote: > > > > I find it very useful if I am allowed to define new local variables in a > > list comprehension. For example, I wish to have something like > > [(x, y) for x in range(10) for y := x ** 2 if

Re: Local variable definition in Python list comprehension

在 2022年9月1日星期四 UTC+2 16:15:17， 写道： > James Tsai writes: > > > I find it very useful if I am allowed to define new local variables in > > a list comprehension. For example, I wish to have something like > > [(x, y) for x in range(10) for y := x ** 2 if x + y <

Re: Local variable definition in Python list comprehension

On 9/1/22, James Tsai wrote: > > I find it very useful if I am allowed to define new local variables in a > list comprehension. For example, I wish to have something like > [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or > [(x, y) for x in range(10) with y := x

Re: Local variable definition in Python list comprehension

On Fri, 2 Sept 2022 at 02:10, James Tsai wrote: > > Hello, > > I find it very useful if I am allowed to define new local variables in a list > comprehension. For example, I wish to have something like > [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or > [

Re: Local variable definition in Python list comprehension

James Tsai writes: > I find it very useful if I am allowed to define new local variables in > a list comprehension. For example, I wish to have something like > [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or > [(x, y) for x in range(10) with y := x ** 2 if x + y <

Local variable definition in Python list comprehension

Hello, I find it very useful if I am allowed to define new local variables in a list comprehension. For example, I wish to have something like [(x, y) for x in range(10) for y := x ** 2 if x + y < 80], or [(x, y) for x in range(10) with y := x ** 2 if x + y < 80]. For now this functionali

Re: Exclude 'None' from list comprehension of dicts

Op 16/08/2022 om 00:20 schreef dn: On 16/08/2022 00.56, Antoon Pardon wrote: Op 5/08/2022 om 07:50 schreef Loris Bennett: Antoon Pardon   writes: Op 4/08/2022 om 13:51 schreef Loris Bennett: Hi, I am constructing a list of dictionaries via the following list comprehension:     data

Re: Exclude 'None' from list comprehension of dicts

On 16/08/2022 00.56, Antoon Pardon wrote: > Op 5/08/2022 om 07:50 schreef Loris Bennett: >> Antoon Pardon  writes: >> >>> Op 4/08/2022 om 13:51 schreef Loris Bennett: >>>> Hi, >>>> >>>> I am constructing a list of dictionaries v

Re: Exclude 'None' from list comprehension of dicts

Op 5/08/2022 om 07:50 schreef Loris Bennett: Antoon Pardon writes: Op 4/08/2022 om 13:51 schreef Loris Bennett: Hi, I am constructing a list of dictionaries via the following list comprehension: data = [get_job_efficiency_dict(job_id) for job_id in job_ids] However

RE: Exclude 'None' from list comprehension of dicts

: Exclude 'None' from list comprehension of dicts Antoon Pardon writes: > Op 4/08/2022 om 13:51 schreef Loris Bennett: >> Hi, >> >> I am constructing a list of dictionaries via the following list >> comprehension: >> >>data = [get_job_efficiency_dict(job_i

Re: Exclude 'None' from list comprehension of dicts

Antoon Pardon writes: > Op 4/08/2022 om 13:51 schreef Loris Bennett: >> Hi, >> >> I am constructing a list of dictionaries via the following list >> comprehension: >> >>data = [get_job_efficiency_dict(job_id) for job_id in job_ids] >> >&g

Re: Exclude 'None' from list comprehension of dicts

. *** On 2022-08-04 12:51, Loris Bennett wrote: Hi, I am constructing a list of dictionaries via the following list comprehension: data = [get_job_efficiency_dict(job_id) for job_id in job_ids] However, get_job_efficiency_dict(job_id) uses 'subprocess.Popen' to run an external program and this can

Re: Exclude 'None' from list comprehension of dicts

On 2022-08-04 12:51, Loris Bennett wrote: Hi, I am constructing a list of dictionaries via the following list comprehension: data = [get_job_efficiency_dict(job_id) for job_id in job_ids] However, get_job_efficiency_dict(job_id) uses 'subprocess.Popen' to run an external program

Re: Exclude 'None' from list comprehension of dicts

Op 4/08/2022 om 13:51 schreef Loris Bennett: Hi, I am constructing a list of dictionaries via the following list comprehension: data = [get_job_efficiency_dict(job_id) for job_id in job_ids] However, get_job_efficiency_dict(job_id) uses 'subprocess.Popen' to run an external program

Exclude 'None' from list comprehension of dicts

Hi, I am constructing a list of dictionaries via the following list comprehension: data = [get_job_efficiency_dict(job_id) for job_id in job_ids] However, get_job_efficiency_dict(job_id) uses 'subprocess.Popen' to run an external program and this can fail. In this case, the dict should

Re: Exclude 'None' from list comprehension of dicts

r...@zedat.fu-berlin.de (Stefan Ram) writes: > "Loris Bennett" writes: >>data = [get_job_efficiency_dict(job_id) for job_id in job_ids] > ... >>filtered_data = list(filter(None, data)) > > You could have "get_job_efficiency_dict" return an iterable > that yields either zero dictionaries or

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: This was fixed in 3.10.0 if I am not mistaken. Could you provide a reproducer, please? -- ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Peter Roelants added the comment: If I understand correctly this should be fixed? In which 3.10.* version should this be fixed? The reason why I'm asking is that I ran into this issue when using Dask (2022.02.0) with multithreading on Python 3.10.2: Exception in thread Profile: Traceback

[issue46549] Error in list comprehension conditionals when used in class attributes

Dennis Sweeney added the comment: See also https://stackoverflow.com/questions/13905741/accessing-class-variables-from-a-list-comprehension-in-the-class-definition -- resolution: -> not a bug stage: -> resolved status: open -> closed _

[issue46549] Error in list comprehension conditionals when used in class attributes

Dennis Sweeney added the comment: I believe this is a duplicate of bpo-45899 -- nosy: +Dennis Sweeney ___ Python tracker ___ ___

[issue46549] Error in list comprehension conditionals when used in class attributes

New submission from din14970 : I discovered this one by accident. When using a conditional inside a list comprehension in class attributes one can get some unexpected behavior. The following does not work: ``` class TestClass: list_1 = [1, 2, 3, 4, 5] exclude = [2, 4] list_2 = [i

[issue46302] IndexError inside list comprehension + workaround

Pierre Fortin added the comment: [Thanks for the replies! I was trying to post this before seeing them.] Major egg on face... The more complex the code becomes, the more likely you will be burned by a rookie mistake... var = '' var[0] WILL give IndexError -- Duh! It was buried in the

[issue46302] IndexError inside list comprehension + workaround

Steven D'Aprano added the comment: Your functions test1 and test2 are irrelevant to the bug report. The driver code using eval() to pick which function to call is unneeded. The business of simulating a file is complexity for no purpose. Those ignore, count, unique functions are also

[issue46302] IndexError inside list comprehension + workaround

Stefan Pochmann added the comment: The error occurs when you do code.strip()[0] when code is " ", not "u2". -- nosy: +Stefan Pochmann ___ Python tracker ___

[issue46302] IndexError inside list comprehension + workaround

Steven D'Aprano added the comment: > it returns IndexError (instead of "u") if used in a list comprehension Works as expected inside a list comprehension: >>> var = "u2" >>> [var.strip()[0] for i in range(2)] ['u', 'u'] >>> ["ok"

[issue46302] IndexError inside list comprehension + workaround

New submission from Pierre Fortin : var = "u2" var.strip()[0] Works as expected, except that it returns IndexError (instead of "u") if used in a list comprehension -- at least, that's where I found it. Attached example script illustrates the issue. Call it with &qu

[issue45899] NameError on if clause of class-level list comprehension

Matthew Barnett added the comment: It's not just in the 'if' clause: >>> class Foo: ... a = ['a', 'b'] ... b = ['b', 'c'] ... c = [b for x in a] ... Traceback (most recent call last): File "", line 1, in File "", line 4, in Foo File "", line 4, in NameError: name 'b' is

[issue45899] NameError on if clause of class-level list comprehension

Mark Dickinson added the comment: This is expected behaviour. See the docs here: https://docs.python.org/3.9/reference/executionmodel.html#resolution-of-names > The scope of names defined in a class block is limited to the class block; it > does not extend to the code blocks of methods –

[issue45899] NameError on if clause of class-level list comprehension

Change by ThiefMaster : -- nosy: +ThiefMaster ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45899] NameError on if clause of class-level list comprehension

New submission from jhpfjyne : Accessing an attribute defined at class-level in the if clause of a list comprehension at class-level throws a NameError. >>> class Foo: ... a = ['a', 'b'] ... b = ['b', 'c'] ... c = [x for x in a if x not in b] ... Traceback (most recent

[issue45862] Anomaly of eval() of list comprehension

Mark Dickinson added the comment: True: there's another detail here that's needed to explain the behaviour. The first "for" clause in a list comprehension is special: it's evaluated in the enclosing scope, rather than in the local function scope that the list comprehension cr

[issue45862] Anomaly of eval() of list comprehension

hanks for the report. The behaviour is by design: see #5242 (especially msg81898) for an explanation. Closing this issue as a duplicate of #5242. -- nosy: +mark.dickinson resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> eval() function in

[issue45862] Anomaly of eval() of list comprehension

Mark Dickinson added the comment: See also #41216 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45862] Anomaly of eval() of list comprehension

t; closed superseder: -> eval() function in List Comprehension doesn't work ___ Python tracker <https://bugs.python.org/issue45862> ___ ___ Python-bugs-list mailing list U

[issue45862] Anomaly of eval() of list comprehension

g def1', [b for b in a_anomaly]) print('eg def2', eval('[b for b in a_anomaly]')) print('eg def3', [e for e in emp for b in a_anomaly if e["mgr"] == b["empno"]]) print('eg def4', eval('[e for e in emp for b in a_anomaly if

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: Feel free to reopen if we are missing anything -- ___ Python tracker ___ ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Pablo Galindo Salgado : -- priority: release blocker -> ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: New changeset 61eb9b5dfd919ba5d1ec9f7df0137f2e6d196972 by Pablo Galindo in branch '3.10': [3.10] bpo-6: support lineno being None in traceback.FrameSummary (GH-26781) (GH-27072)

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Pablo Galindo Salgado : -- pull_requests: +25623 pull_request: https://github.com/python/cpython/pull/27072 ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: New changeset 91a8f8c16ca9a7e2466a8241d9b41769ef97d094 by Filipe Laíns in branch 'main': bpo-6: support lineno being None in traceback.FrameSummary (GH-26781) https://github.com/python/cpython/commit/91a8f8c16ca9a7e2466a8241d9b41769ef97d094

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: The issue that made the line number be missing is fixed, but GH-26781 is needed to account for 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b, even though it is no longer triggered in this situation. -- ___ Python tracker

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: Beta 4 is in a few days. Can someone confirm of this is fixed or if it still needs a patch? -- ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Mark Shannon added the comment: With the latest 3.10, I get: File "/home/mark/test/test.py", line 13, in next(bar().__await__(), None) File "/home/mark/test/test.py", line 10, in bar return [chunk async for chunk in foo()] File "/home/mark/test/test.py", line 10, in return

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Mark Shannon added the comment: This appears to be a duplicate of https://bugs.python.org/issue44297 -- ___ Python tracker ___ ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Pablo Galindo Salgado : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Pablo Galindo Salgado added the comment: Mark, can you take a look at this? -- nosy: +pablogsal versions: +Python 3.11 -Python 3.10 ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: Upon further investigation, there are actually two issues here. The first would be the one I identified already, traceback.FrameSummary not being prepared for lineno being None, but there is also a regression in lineno being invalid in this situation in the

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- pull_requests: +25367 pull_request: https://github.com/python/cpython/pull/26782 ___ Python tracker ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: I bissected this to 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b and submitted a patch making traceback.FrameSummary take into consideration that lineno might be None, I believe this is probably the correct fix. -- ___

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- keywords: +patch nosy: +FFY00 nosy_count: 4.0 -> 5.0 pull_requests: +25366 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26781 ___ Python tracker

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- nosy: +iritkatriel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Thomas Grainger : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Thomas Grainger : -- nosy: +Mark.Shannon -nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Ned Batchelder : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

rity: normal status: open title: linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue6> ___

[issue43161] Taking sum of massive list comprehension results in total system crash.

Mark Dickinson added the comment: > 28 bytes for the actual object Gah. I should proof-read before hitting "Submit Changes". That should say "28 bytes for each int object". -- ___ Python tracker

[issue43161] Taking sum of massive list comprehension results in total system crash.

Mark Dickinson added the comment: The list you're attempting to create needs around 41GB of RAM (28 bytes for the actual object, rounded up to 32 bytes per object for alignment reasons, plus 8 bytes for each pointer in the list). Assuming you don't have that much memory on your system,

[issue43161] Taking sum of massive list comprehension results in total system crash.

George added the comment: Thanks Christian for the solutions. I am guessing that since it is my entire machine that crashes, and python is not simply killed for requesting so much memory, that this is an operating system problem. Should I submit this as a bug to the kernel project then?

[issue43161] Taking sum of massive list comprehension results in total system crash.

Christian Heimes added the comment: You are using a list comprehension that consumes a LOT of memory very fast. The line requires more physical RAM than available on a typical user system. This causes your computer to become unresponsive to input. You can rewrite tie list comprehension

[issue43161] Taking sum of massive list comprehension results in total system crash.

as I want to know the result of the computation. Unless, of course it is harebrained, then we should ignore because Guido already discussed such computations. George -- messages: 386615 nosy: U9dB37BPZx priority: normal severity: normal status: open title: Taking sum of massive list compreh

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Batuhan Taskaya added the comment: > This can be closed, but for completeness, the test you ran didn't verify that > the bug was fixed. This is because the hard coded compile flags I gave in my > example seem to have changed in Python 3.9 (is this documented?). Yes, this is documented on

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Jonathan Crall added the comment: This can be closed, but for completeness, the test you ran didn't verify that the bug was fixed. This is because the hard coded compile flags I gave in my example seem to have changed in Python 3.9 (is this documented?). In python3.8 the compile flags I

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

STINNER Victor added the comment: > I first noticed this when testing xdoctest on Python 3.9, and then again when > using IPython. What is your Python 3.9 exact version number? I cannot reproduce your issue with Python 3.9.0a6: vstinner@apu$ ./python -c "print(eval(compile('[i for i in

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

STINNER Victor added the comment: I close the issue: it's already fixed in 3.9.0a6. If it's not the case, feel free to reopen the issue ;-) -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Jonathan Crall added the comment: Ah, sorry. I neglected all the important information. I tested this using: Python 3.9.0a5 (default, Apr 23 2020, 14:11:34) [GCC 8.3.0] Specifically, I ran in a docker container: DOCKER_IMAGE=circleci/python:3.9-rc docker pull $DOCKER_IMAGE docker run

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40438] Python 3.9 eval on list comprehension sometimes returns coroutines

I can't find any notes in the CHANGELOG that seem to correspond to it. -- components: Interpreter Core messages: 367651 nosy: Jonathan Crall priority: normal severity: normal status: open title: Python 3.9 eval on list comprehension sometimes returns coroutines vers

[issue38970] [PDB] NameError in list comprehension in PDB

Karthikeyan Singaravelan added the comment: I think this is same as https://bugs.python.org/issue26072#msg277578 and is reproducible with below sample script without depending on turbogears. The attached patch in the issue fixes this. Try using interact command from pdb as a workaround.

[issue38970] [PDB] NameError in list comprehension in PDB

w how to report the issue in a reproducible way. Thanks -- components: Library (Lib) messages: 357807 nosy: castix priority: normal severity: normal status: open title: [PDB] NameError in list comprehension in PDB type: behavior versions: Python 3.7

[issue38937] NameError in list comprehension within .pth file

: "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition" So the new scope made by the list comprehension can't access the enclosing scope in which the new variable was defined, because that's how scoping works

[issue38937] NameError in list comprehension within .pth file

Change by Roundup Robot : -- keywords: +patch pull_requests: +16895 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17414 ___ Python tracker ___

[issue38937] NameError in list comprehension within .pth file

Chris Billington added the comment: I see. site.py calls exec() from within a function, and therefore the code is executed in the context of that function's locals and the site module globals. This means the code in .pth files can access (but not add new) local names from the

[issue38937] NameError in list comprehension within .pth file

e "help", "copyright", "credits" or "license" for more information. >>> I know .pth file processing is very early in interpreter startup such that many things aren't working yet, but I wouldn't expect using a name defined outside a list comprehensio

[issue38847] AST Optimization for Single Target List Comprehension

Raymond Hettinger added the comment: I concur with Pablo. Thank you for the suggestion though. -- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue38847] AST Optimization for Single Target List Comprehension

Pablo Galindo Salgado added the comment: IMHO, I think is such a specific use case that is not worth the maintenance cost. Especially because of such list comprehension is very uncommon as you can simply do `list(it)` which more readable and anecdotally faster. -- nosy: +pablogsal

[issue38847] AST Optimization for Single Target List Comprehension

Change by Batuhan : -- components: +Interpreter Core versions: +Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38847] AST Optimization for Single Target List Comprehension

ver set (`{x for x in it}`) comprehensions? -- messages: 356965 nosy: BTaskaya, inada.naoki priority: normal severity: normal status: open title: AST Optimization for Single Target List Comprehension ___ Python tracker <https://bugs.python.org/issu

[issue38847] AST Optimization for Single Target List Comprehension

Change by Batuhan : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37646] eval() in a list comprehension

Raymond Hettinger added the comment: New changeset 9341dcb4b9520ab92df10d4256e93a50e1e7d19f by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37646: Document that eval() cannot access nested scopes (GH-15117) (GH-15155)

[issue37646] eval() in a list comprehension

Change by Raymond Hettinger : -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue37646] eval() in a list comprehension

Change by miss-islington : -- pull_requests: +14888 pull_request: https://github.com/python/cpython/pull/15155 ___ Python tracker ___

[issue37646] eval() in a list comprehension

Raymond Hettinger added the comment: New changeset 610a4823cc0a3c2380ad0dfe64ae483ced4e5304 by Raymond Hettinger in branch 'master': bpo-37646: Document that eval() cannot access nested scopes (GH-15117) https://github.com/python/cpython/commit/610a4823cc0a3c2380ad0dfe64ae483ced4e5304

[issue37646] eval() in a list comprehension

Raymond Hettinger added the comment: After more thought, I think the existing behavior is probably what we want. There may not be a clean way to allow access and updates to non-locals. Even if a way was found, it may tie our hands and preclude other implementation changes down the road.

[issue37646] eval() in a list comprehension

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +14858 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15117 ___ Python tracker

[issue37646] eval() in a list comprehension

Grzegorz Krasoń added the comment: I re-opened the issue. Dear core developers, can we ask you to confirm if described behavior of eval() is expected? -- ___ Python tracker

[issue37646] eval() in a list comprehension

Change by Grzegorz Krasoń : -- resolution: not a bug -> status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing

[issue37646] eval() in a list comprehension

Steven D'Aprano added the comment: I'm not sure we should be so quick to close this. At the very least, I think the documentation could be improved. It does seem desirable to have the invariant: `expression` == `eval("expression")` apply in any environment. Was the change in behaviour

[issue37646] eval() in a list comprehension

Grzegorz Krasoń added the comment: Steven, I believed that any `` replaced by `eval('')` will not change behaviour of the code. Now I understand that my assumption was incorrect. Raymond, thanks for helping me understand this. -- resolution: -> not a bug stage: -> resolved status:

[issue37646] eval() in a list comprehension

Raymond Hettinger added the comment: This used to work as you expected in Python 2. In Python 3, list comprehensions create their own inner scope just like generator expressions. Per the eval() docs, "if both dictionaries are omitted, the expression is executed in the environment where

[issue37646] eval() in a list comprehension

Steven D'Aprano added the comment: What leads you to believe that eval *shouldn't* work in the global scope in a comprehension? If not the global scope, which scope should it be, local or nonlocal? Is the behaviour documented differently? For reference, the current docs for eval are here:

[issue37646] eval() in a list comprehension

New submission from Grzegorz Krasoń : eval() works in a global scope when invoked in a list comprehension. -- components: Interpreter Core files: demo.py messages: 348271 nosy: Grzegorz Krasoń priority: normal severity: normal status: open title: eval() in a list comprehension type

[issue36158] Regex search behaves differently in list comprehension

Change by Josh Rosenberg : -- resolution: -> not a bug stage: -> resolved status: pending -> closed ___ Python tracker ___ ___

  1   2   3   4   5   6   7   8   9   >