[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 ___ ___ Python-bugs-list mailing li

[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 ___ ___

[issue2292] Missing *-unpacking generalizations

Yury Selivanov added the comment: Do we need to make lib2to3 compatible with the new grammar? -- nosy: +yselivanov ___ Python tracker ___ _

[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 ___ _

[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 L

[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 undefi

[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] >>>

[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

[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

Changes by Berker Peksag : -- stage: patch review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Thanks Benjamin! On May 5, 2015 5:17 PM, "Benjamin Peterson" wrote: > > Benjamin Peterson added the comment: > > a65f685ba8c0 > > -- > resolution: -> fixed > status: open -> closed > > ___ > Python tracker >

[issue2292] Missing *-unpacking generalizations

Changes by Benjamin Peterson : -- assignee: twouters -> benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: a65f685ba8c0 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bug

[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 m

[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 wrote: > Yeah, but the docs don't need to be committed in time for beta 1. The > source code should go in ASAP, especially s

[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, Ma

[issue2292] Missing *-unpacking generalizations

Benjamin Peterson added the comment: It certainly would be nice to have documentation. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Thanks for the review Thomas! And yes, that's what I meant. :-) -- ___ Python tracker ___ ___ Pytho

[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 ch

[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

Changes by Neil Girdhar : Added file: http://bugs.python.org/file39059/starunpack41.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[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, bu

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file38856/starunpack40.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[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 __

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file38611/starunpack38.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue2292] Missing *-unpacking generalizations

Changes by Brett Cannon : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file38429/starunpack37.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: All tests pass on my ubuntu 13.04 system. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file38395/starunpack36.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[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 ___ _

[issue2292] Missing *-unpacking generalizations

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

[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 ___

[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

[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 ___

[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 change

[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 merge

[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

Changes by Neil Girdhar : Added file: http://bugs.python.org/file38062/starunpack31.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: All test pass on my system. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[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 ___ _

[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 ___ ___ Python-bu

[issue2292] Missing *-unpacking generalizations

Ethan Furman added the comment: Argh -- I applied the patch, but didn't recompile. Doing that now... -- ___ Python tracker ___ ___ Pyt

[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 __

[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 x86_64).

[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: http://bugs.python.org/file37928

[issue2292] Missing *-unpacking generalizations

Changes by Éric Araujo : -- nosy: -eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue2292] Missing *-unpacking generalizations

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

[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" wrote: > > Neil Girdhar added the comment: > > Is it possible to edit the PEP to reflect the current design decisio

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Fixed a bug in ceval.c; added a test to test_unpack_ex. -- ___ Python tracker ___ ___ Python-bugs-list

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file37924/starunpack28.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file37925/starunpack28.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[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: "C

[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 ___

[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

[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 wrote: > > Neil Girdhar a

[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: http://bugs.python.org/file37911/starunpack25.d

[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 "", line 1, in parser.ParserError: Expected node type 12, got 302. -- _

[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 _

[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 : Added file: http://bugs.python.org/file37876/starunpack22.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[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

[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: http://bugs.python

[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 fo

[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

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. But

[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 ___

[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" 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 Girdhar" w

[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" wrote: > > Neil Girdhar added the comment: > > >>> def f(a, *b): print(list(a), list(b)) > > -- >

[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 f(

[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 "", line 1 f(**i for i in ['abc', 'def']) ^ SyntaxError: invalid syntax Should neither work? Both? -- ___

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: >>> def f(a, *b): print(list(a), list(b)) -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: Both. On Jan 26, 2015 8:42 AM, "Neil Girdhar" 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 "", line 1 > f(**i for i

[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 __

[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: 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 ___

[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 tracker

[issue2292] Missing *-unpacking generalizations

Changes by Chris Angelico : -- nosy: -Rosuav ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue2292] Missing *-unpacking generalizations

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

[issue2292] Missing *-unpacking generalizations

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

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: I was also thinking of unifying it all, but I couldn't find a way to ensure that the most common case (which I assume is f(x, y, z=0, w=0, *args, **kwargs)) produces no additional opcodes. If you have a nice unification, I look forward to it. -- _

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Ah, sorry, yes, this is what I meant (and I see what your'e trying to fix now!): >>> import dis >>> def f(x,y): pass ... >>> dis.dis("f(y=1, **{'x': 1}, x=2)") 1 0 LOAD_NAME0 (f) 3 LOAD_CONST 0 ('y')

[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: Just before any arguments to the function. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: when does that get pushed on the stack? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: The function object that's on the stack. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: What do you mean by the stack will "have the function"? At the point that you're doing BUILD_MAP_UNPACK, CALL_FUNCTION hasn't been executed… -- ___ Python tracker _

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: The stack will have the function, then any number of positional arguments, then optionally an *args, then any number (>= 2) of maps to unpack. To get to the function, you need to know the sum count of all of these. -- __

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: That's true. But wouldn't the offset always be one (or three or whatever) since if we do BUILD_MAP_UNPACK in a function call it's always right before CALL_FUNCTION? -- ___ Python tracker

[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 'a

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Okay, I didn't realize it was so simple to raise the error from somewhere else. Regarding "duplicate the (large) dictionary merging function" — of course we would just factor it out into a function. -- ___ Python tra

[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 + n

[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 cod

[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 checking

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Why would that simplify things? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[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

  1   2   3   >