[Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!
Chris Angelico
rosuav at gmail.com
Thu Apr 26 11:21:13 EDT 2018
More information about the Python-Dev mailing list
Thu Apr 26 11:21:13 EDT 2018
- Previous message (by thread): [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!
- Next message (by thread): [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum <guido at python.org> wrote: > Just as I feared. While currently fixing this is just fixing a bug (nobody's > code is going to break except perhaps some tests), with PEP 572 fixing this > would be mandatory. > > On Thu, Apr 26, 2018 at 6:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: >> >> On 25 April 2018 at 18:23, Chris Angelico <rosuav at gmail.com> wrote: >> >>>> x={print(2): print(1) for _ in [1]} >> > 1 >> > 2 >> > >> > Hmmmmmmmmm. One of these is not like the others... >> >> Huh, it looks like we missed checking dict comprehensions when we >> fixed dict displays to evaluate keys before the corresponding values. >> That would qualify as a reasonable request for improvement in Python >> 3.8 :) It's deliberate code in compile.c: case COMP_DICTCOMP: /* With 'd[k] = v', v is evaluated before k, so we do the same. */ VISIT(c, expr, val); VISIT(c, expr, elt); ADDOP_I(c, MAP_ADD, gen_index + 1); break; So if it's a bug, it's still a deliberate bug. :) ChrisA
- Previous message (by thread): [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!
- Next message (by thread): [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list