[issue2292] Missing *-unpacking generalizations

Serhiy Storchaka added the comment: Issue26213 was opened for documenting bytecode changes. But 21 months and 3 releases after the code patch the documentation is still not updated. -- nosy: +larry, serhiy.storchaka ___ Python tracker

[issue2292] Missing *-unpacking generalizations

Terry J. Reedy added the comment: > the docs don't need to be committed in time for beta 1. 10 months and 2 releases after the code patch, the doc patches in #24136 are incomplete (I believe), uncommitted, untouched since July, and forgotten about. The issue needs more help. --

[issue2292] Missing *-unpacking generalizations

Ezio Melotti added the comment: I created #25969 to track the lib2to3 update. -- ___ Python tracker ___ ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Yes we should. I'd consider it a bug if it wasn't supported in 3.5.0 and we could fix that bug in 3.5.1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Yury Selivanov added the comment: Do we need to make lib2to3 compatible with the new grammar? -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: I think it's fine. It collects all the keys and values and then calls BUILD_MAP (a new opcode), rather than calling STORE_MAP for each key/value pair. I think this is a reasonable strategy for compiling a dict display. On Thu, May 7, 2015 at 11:40 AM, Joshua

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: There is a change as part of this to make dict building more like list and set building, which both have this behaviour. The same changes have likely occurred before whenever BUILD_LIST and BUILD_SET were introduced, and this behaviour seems particularly

[issue2292] Missing *-unpacking generalizations

Stefan Behnel added the comment: I get a test failure in Cython's compatibility tests which seems to be attributable to this change: def sideeffect(x): ... L.append(x) ... return x def unhashable(x): ... L.append(x) ... return [x] L = []

[issue2292] Missing *-unpacking generalizations

Nick Coghlan added the comment: This could likely stand to be clarified in the language reference, though (as well as in the 3.5 porting notes) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Thomas Wouters added the comment: FYI, I meant last Monday, but I forgot it was May 4th (Dutch Memorial day) and May 5th (Dutch Liberation day), so that got in the way :P Should we keep this bug open for docs changes, or is there a separate issue for that? --

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: On Wed, May 6, 2015, at 09:15, Thomas Wouters wrote: Thomas Wouters added the comment: FYI, I meant last Monday, but I forgot it was May 4th (Dutch Memorial day) and May 5th (Dutch Liberation day), so that got in the way :P Should we keep this bug

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: (To clarify, the PEP itself probably serves as enough documentation in the interim.) On Tue, May 5, 2015 at 4:47 PM, Guido van Rossum gu...@python.org wrote: Yeah, but the docs don't need to be committed in time for beta 1. The source code should go in

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Yeah, but the docs don't need to be committed in time for beta 1. The source code should go in ASAP, especially since the PEP 492 changes will have to be merged in on top of them. @Thomas: which Monday were you shooting for? I had hoped yesterday... On Sat,

[issue2292] Missing *-unpacking generalizations

Changes by Berker Peksag berker.pek...@gmail.com: -- stage: patch review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Thanks Benjamin! On May 5, 2015 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson added the comment: a65f685ba8c0 -- resolution: - fixed status: open - closed ___ Python tracker

[issue2292] Missing *-unpacking generalizations

Changes by Benjamin Peterson benja...@python.org: -- assignee: twouters - benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: a65f685ba8c0 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: On Tue, May 5, 2015, at 19:48, Guido van Rossum wrote: Guido van Rossum added the comment: Yeah, but the docs don't need to be committed in time for beta 1. The source code should go in ASAP, especially since the PEP 492 changes will have to be merged

[issue2292] Missing *-unpacking generalizations

Thomas Wouters added the comment: The latest patch looks good to me. No need to do the additional AST refactoring if it's going to make PEP 492's implementor's life harder (but I do read Guido's comment as a reason to check this in sooner rather than later :) So, unless anyone objects I'll

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Thanks for the review Thomas! And yes, that's what I meant. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: It certainly would be nice to have documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: All tests pass. All reviewer comments addressed. Please let me know if anything else needs to be done from my end. -- Added file: http://bugs.python.org/file39230/starunpack42.diff ___ Python tracker

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Hi Steve: I have limited expertise in most of these areas, but I looked at starunpack40.diff and have these comments: * tests look to have good coverage of the feature (can't speak to coverage of the parser/compiler code) * parsermodule.c changes comprehension

[issue2292] Missing *-unpacking generalizations

Steve Dower added the comment: I have limited expertise in most of these areas, but I looked at starunpack40.diff and have these comments: * tests look to have good coverage of the feature (can't speak to coverage of the parser/compiler code) * parsermodule.c changes comprehension handling,

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file39059/starunpack41.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38856/starunpack40.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38611/starunpack38.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Removed a confusing and outdated comment in Lib/importlib/_bootstrap.py -- Added file: http://bugs.python.org/file38613/starunpack39.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Changes by Brett Cannon br...@python.org: -- priority: normal - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38429/starunpack37.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: All tests pass on my ubuntu 13.04 system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38395/starunpack36.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Removed dead code. Awaiting code review! :) -- Added file: http://bugs.python.org/file38341/starunpack35.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: New changelist for updated patch (before merging changes). -- Added file: http://bugs.python.org/file38252/starunpack33.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Finished merge. -- Added file: http://bugs.python.org/file38253/starunpack34.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: The patch no longer applies cleanly. I had to do hg up -r ac0d6c09457e to get a checkpoint to which it applies. (But I'm not sure at what point that landed me.) -- ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file38062/starunpack31.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: For starters, it would be nice if the patch didn't make unrelated style changes (e.g. in compile.c). I also Call arguments should be unified into one list rather than distinguishing between keywords and args anymore. -- nosy: +benjamin.peterson

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Thank you, Benjamin. It's my nature to keep code consistent/clean, but I realize that I can get carried away. Should I revert all incidental PEP 7 style changes? Regarding the args/keywords, where do you mean? If you're talking about compile.c, we can't

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: On Mon, Feb 9, 2015, at 18:15, Neil Girdhar wrote: Neil Girdhar added the comment: Thank you, Benjamin. It's my nature to keep code consistent/clean, but I realize that I can get carried away. Should I revert all incidental PEP 7 style changes?

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Removed incidental PEP 7 changes and reran tests. -- Added file: http://bugs.python.org/file38070/starunpack32.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: All test pass on my system. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: I don't know the etiquette rules for the issue tracker, but I'd really appreciate having something to debug -- it's working for me, you see. -- ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: Thanks, Terry! I'll do that next time -- after I make sure and re-compile. :/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: Argh -- I applied the patch, but didn't recompile. Doing that now... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Terry J. Reedy added the comment: Upload a .txt file if there is really too much for a message. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: Tried running tests, tests that failed with patch: test_ast test_collections test_extcall test_grammar test_importlib test_parser test_syntax test_unpack_ex test_zipfile Running Ubuntu 13.04 (GNU/Linux 3.8.0-22-generic

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Another bug, another test. -- Added file: http://bugs.python.org/file37926/starunpack29.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Fixed a bug in ceval.c; added a test to test_unpack_ex. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37925/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: For the PEP update, please check out the PEP repo at hg.python.org and send a patch to p...@python.org. On Jan 30, 2015 3:54 AM, Neil Girdhar rep...@bugs.python.org wrote: Neil Girdhar added the comment: Is it possible to edit the PEP to reflect the

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Removed file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Special-cased `(*i for i in x)` to use YIELD_FROM instead of looping. Speed improved, albeit still only half as fast as chain.from_iterable. Fixed error message check in test_syntax and removed semicolons. -- Added file:

[issue2292] Missing *-unpacking generalizations

Changes by Éric Araujo mer...@netwok.org: -- nosy: -eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Ready for a code review: Blocked f(*x for x…) as requested. Polished up parsermodule.c. -- Added file: http://bugs.python.org/file37920/starunpack26.diff ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Is it possible to edit the PEP to reflect the current design decisions? Specifically: * Remove: Because of the new levity for * and ** unpackings, it may be advisable to lift some or all of these restrictions. (in both abstract and specification) * Extend:

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Fixed a bug and added a test. -- Added file: http://bugs.python.org/file37921/starunpack27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: All tests pass. @Guido: can we get some clarification on f(*… and f(**…? One option is to make them illegal for now and then open them up in a future PEP when it's more clear what's wanted? -- Added file:

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Hi Neil, I think disallowing them is the best approach. There doesn't seem to be a good use case that would be thwarted. Hopefully the syntactic prohibition isn't too hard to implement. On Thu, Jan 29, 2015 at 4:32 PM, Neil Girdhar rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Fixed a couple bugs and added a test. Incremented the magic number. -- Added file: http://bugs.python.org/file37896/starunpack24.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Just need to fix the parser now. Minimal example: parser.sequence2st(parser.expr({1}).totuple()) Traceback (most recent call last): File stdin, line 1, in module parser.ParserError: Expected node type 12, got 302. --

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: def f(a, *b): print(list(a), list(b)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Is this correct? f(*i for i in ['abc', 'def']) ['a', 'b', 'c', 'd', 'e', 'f'] [] f(**i for i in ['abc', 'def']) File stdin, line 1 f(**i for i in ['abc', 'def']) ^ SyntaxError: invalid syntax Should neither work? Both? --

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Both. On Jan 26, 2015 8:42 AM, Neil Girdhar rep...@bugs.python.org wrote: Neil Girdhar added the comment: Is this correct? f(*i for i in ['abc', 'def']) ['a', 'b', 'c', 'd', 'e', 'f'] [] f(**i for i in ['abc', 'def']) File stdin, line 1

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Quick-fix for Guido's bug attached. I'm not familiar with this part of the code, yet, so take this tentatively. I just changed while (containers 1) { to while (containers) { --- @Guido My comments were assuming `f(**x for x in y)` meant `f({**x

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Update for the error messages fix. I've put aside the idea of unifying things for now because there are a couple of interdependencies I wasn't expecting and I absolutely don't want the fast-path for f(x) to get slower. -- Added file:

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Could you help me understand this a bit better? I always thought of f(x for x in l) as equivalent to f( (x for x in l) ). So, I can see that f(*x for x in l) should be equivalent to f( (*x for x in l) ). How should we interpret f(**x for x in l)? Is it then

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: So I think the test function here should be: def f(*a, **k): print(list(a), list(k)) Then we can try things like: f(x for x in ['ab', 'cd']) which prints a generator object, because this is interpreted as an argument that's a generator expression.

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Let's wait until I have a keyboard. In 20 min. On Jan 26, 2015 8:55 AM, Guido van Rossum gu...@python.org wrote: Wait, with that f() definition I'd expect a different result from the former -- each letter as a new arg. Right? On Jan 26, 2015 8:42 AM, Neil

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Wait, with that f() definition I'd expect a different result from the former -- each letter as a new arg. Right? On Jan 26, 2015 8:42 AM, Neil Girdhar rep...@bugs.python.org wrote: Neil Girdhar added the comment: def f(a, *b): print(list(a), list(b))

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: @Joshua: Re: f(x: y for x, y in z) I don't think that follows at all. We support f(**d) now, but if d == {'a': 1, 'b': 2}, it is equivalent to f(a=1, b=2), not f(a: 1, b: 2). -- ___ Python tracker

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: If we're supporting f(**x for x in y) surely we should also support f(x: y for x, y in z) I personally don't like this idea. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Everything seems to work except two tests are still failing: parser and venv. Any ideas Joshua? Also, we have to decide what to do with f(*x for x in l) and f(**x for x in l). -- Added file: http://bugs.python.org/file37877/starunpack23.diff

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37876/starunpack22.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: fixed a minor bug with the function address, and made a number of polishing changes. -- Added file: http://bugs.python.org/file37871/starunpack21.diff ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Fixed all tests except test_parser. New node numbers are not reflected here for some reason. -- Added file: http://bugs.python.org/file37854/starunpack18.diff ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Dict comprehensions work. -- Added file: http://bugs.python.org/file37852/starunpack16.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Amazing, thanks. I also just uncovered http://bugs.python.org/issue23316; we'll need to support a patch for that. In fact, bad evaluation order is why I haven't yet gotten down my unification strategy. I wouldn't worry about extra opcodes when using *args or

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Dict displays work. -- Added file: http://bugs.python.org/file37851/starunpack15.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Chris Angelico ros...@gmail.com: -- nosy: -Rosuav ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: All tests pass, polishing. Joshua, I'm still not sure how to do show the right error for the function call with duplicate arguments… -- Added file: http://bugs.python.org/file37853/starunpack17.diff ___ Python

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Sounds good. I'll stop working until I see your patch. I tried to make it easy for you to implement your error idea wrt BUILD_MAP_UNPACK :) -- ___ Python tracker rep...@bugs.python.org

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37821/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar mistersh...@gmail.com: Removed file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: By the way, Joshua if you wanted to edit the text of the PEP, it might be nice to point out that this replaces itertools.chain.from_iterable. I know you mention one use of itertools.chain, but I think this nicely replaces all uses of both: itertools.chain(a,

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: I've looked at BUILD_MAP(n). It seems to work and has speed improvements but: - I was wrong about the 16-bit int thing. It turns out CPython is happily treating them as 32 bit as long as they are prefixed by an EXTENDED_ARG bytecode

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: BUILD_MAP(n) -- Added file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___

[issue2292] Missing *-unpacking generalizations

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: -giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Why would that simplify things? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Sorry, I don't know enough about how you were planning on using the stack pointer difference to produce good errors. I thought that if you waited for the CALL_FUNCTION to be happening before reporting errors about duplicate parameters it might simplify that

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: I phrased that badly. Whilst I can see minor simplifications to BUILD_MAP_UNPACK, the only way to add more information to CALL_FUNCTION_XXX would be through EXTENDED_ARG. This seems like it would outweigh any benefits, and the tiny duplication of error

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: In that case, another option would be to use that to send the number of maps to CALL_FUNCTION and let it do the BUILD_MAP_UNPACK stuff itself. Would that simplify your ideas regarding error handling? -- ___ Python

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: We wouldn't actually need to raise it from somewhere else; the line numbering and frame are already correct. The only difficulty is that the traceback currently says # func(a=1, **{'a': 1}) TypeError: func() got multiple values for keyword argument

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: The function object that's on the stack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: when does that get pushed on the stack? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Just before any arguments to the function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: No, that happens in CALL_FUNCTION_KW: import dis dis.dis(f(x=1, **{'x': 1})) 1 0 LOAD_NAME0 (f) 3 LOAD_CONST 0 ('x') 6 LOAD_CONST 1 (1) 9 LOAD_CONST

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Oh, thanks I see, by the LOAD_BUILD_CLASS or VISIT(c, expr, e-v.Call.func) ? Ok, I see. Why do the errors work now for f(x=1, **{'x': 2}) — these are happening at BUILD_MAP_UNPACK without a stack pointer adjustment. For me, the error message mentions 'f'

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: I imagine it like (in the map unpacking code) func_offset = (oparg 8) 0xFF; num_maps = oparg 0xFF; // later if (func_offset) { // do checks if (repeated_argument) { raise_error_from_function(PEEK(func_offset +

  1   2   3   >