[issue2292] Missing *-unpacking generalizations

[Serhiy Storchaka]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Terry J. Reedy]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ezio Melotti]

Ezio Melotti added the comment:

I created #25969 to track the lib2to3 update.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Yury Selivanov]

Yury Selivanov added the comment:

Do we need to make lib2to3 compatible with the new grammar?

--
nosy: +yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Nick Coghlan]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 Landau 
wrote:

>
> 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 undefined.
>
> That said, I did overlook the difference. Hopefully there's agreement that
> it doesn't matter.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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

That said, I did overlook the difference. Hopefully there's agreement that it 
doesn't matter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Stefan Behnel]

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 = []
>>> {1:2, sideeffect(2): 3, 3: 4, unhashable(4): 5, sideeffect(5): 6}# 
doctest: +ELLIPSIS
Traceback (most recent call last):
TypeError: ...unhashable...
>>> L
[2, 4]
"""

Instead, L ends up being [2, 4, 5]. Is this intended? Or acceptable?

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

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 open for docs changes, or is there a separate
> issue for that?

#24136

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Berker Peksag]

Changes by Berker Peksag :


--
stage: patch review -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee: twouters -> benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

Benjamin Peterson added the comment:

a65f685ba8c0

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

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 in on top of them. @Thomas: which Monday were you
> shooting for? I had hoped yesterday...

I suppose I can just do it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 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, May 2, 2015 at 6:52 PM, Benjamin Peterson 
> wrote:
>
>>
>> Benjamin Peterson added the comment:
>>
>> It certainly would be nice to have documentation.
>>
>> --
>>
>> ___
>> Python tracker 
>> 
>> ___
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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, May 2, 2015 at 6:52 PM, Benjamin Peterson 
wrote:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

Benjamin Peterson added the comment:

It certainly would be nice to have documentation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum added the comment:

Thanks for the review Thomas! And yes, that's what I meant. :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

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 check in the latest patch on Monday.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 handling, but I thought we pulled this 
out?

There was some code taken common in various places, but there should be no code 
for unpacking comprehensions left in.   Do you have a question about a specific 
line?

* why was dictobject.c.h added? I don't understand clinic thoroughly, but it 
seems a lot of new code for what was changed in dictobject.c

They weren't added.  They were moved by someone else.  The only changes are 
exposing a method.

* can the BUILD_(TUPLE|LIST)_UNPACK code in ceval.c share most of the 
processing? Or is there an unwanted perf impact to that?

Good idea.  I'll make that change.

* whoever applies the patch should regenerate importlib.h themselves - just a 
reminder

Otherwise, I didn't see anything that particularly scared me. Since we 
apparently don't have anyone willing and with the expertise to thoroughly check 
the patch, I'd vote for checking it in asap so it has more releases to bake 
before 3.5 final.

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file39059/starunpack41.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Steve Dower]

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, but I thought we pulled this 
out?
* why was dictobject.c.h added? I don't understand clinic thoroughly, but it 
seems a lot of new code for what was changed in dictobject.c
* can the BUILD_(TUPLE|LIST)_UNPACK code in ceval.c share most of the 
processing? Or is there an unwanted perf impact to that?
* whoever applies the patch should regenerate importlib.h themselves - just a 
reminder

Otherwise, I didn't see anything that particularly scared me. Since we 
apparently don't have anyone willing and with the expertise to thoroughly check 
the patch, I'd vote for checking it in asap so it has more releases to bake 
before 3.5 final.

--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file38856/starunpack40.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file38611/starunpack38.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Brett Cannon]

Changes by Brett Cannon :


--
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file38429/starunpack37.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ethan Furman]

Ethan Furman added the comment:

All tests pass on my ubuntu 13.04 system.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file38395/starunpack36.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Removed dead code.  Awaiting code review! :)

--
Added file: http://bugs.python.org/file38341/starunpack35.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Finished merge.

--
Added file: http://bugs.python.org/file38253/starunpack34.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

New changelist for updated patch (before merging changes).

--
Added file: http://bugs.python.org/file38252/starunpack33.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Removed incidental PEP 7 changes and reran tests.

--
Added file: http://bugs.python.org/file38070/starunpack32.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

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?

Yes, please.

> 
> Regarding the args/keywords, where do you mean?  If you're talking about
> compile.c, we can't merge them because the call_function operand expects
> to see the positional arguments below the keyword arguments on the stack.

You can ignore this suggestion, since it occurred to me after
misinterpreting the PEP.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 them because the call_function operand expects to see 
the positional arguments below the keyword arguments on the stack.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Benjamin Peterson]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file38062/starunpack31.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ethan Furman]

Ethan Furman added the comment:

All test pass on my system.  :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ethan Furman]

Ethan Furman added the comment:

Thanks, Terry!  I'll do that next time -- after I make sure and re-compile.  :/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Terry J. Reedy]

Terry J. Reedy added the comment:

Upload a .txt file if there is really too much for a message.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ethan Furman]

Ethan Furman added the comment:

Argh -- I applied the patch, but didn't recompile.  Doing that now...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Ethan Furman]

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

Should I copy/paste the errors, email them, or what?  It's going to be a wall 
of text.

--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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/starunpack30.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Éric Araujo]

Changes by Éric Araujo :


--
nosy:  -eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Another bug, another test.

--
Added file: http://bugs.python.org/file37926/starunpack29.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 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: "Currently duplicate arguments raise TypeError.  This remains
> true for duplicate arguments provided through multiple keyword argument
> unpackings, e.g. f(**{'x': 2}, **{'x': 3})
> * Add some examples of dictionary overriding to the list of examples:
>
> >>> {'x': 1, **{'x': 2}}
> {'x': 2}
>
> >>> {**{'x': 2}, 'x': 1}
> {'x': 1}
>
> * Remove "if the restrictions are kept" (they are)
> * Remove "If they are removed completely..."
> * In disadvantages, remove "if the current are kept" (they are).  Don't
> write "* unpackings", write "iterable unpackings"
> * Remove "if the current restrictions are lifted"
> * Remove "Implementation" section (it's done!)
> * Add to specification: "f(*x for x in it) and f(**x for x in it)" remain
> SyntaxErrors.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Removed file: http://bugs.python.org/file37924/starunpack28.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Fixed a bug in ceval.c; added a test to test_unpack_ex.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file37924/starunpack28.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file37925/starunpack28.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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: "Currently duplicate arguments raise TypeError.  This remains true 
for duplicate arguments provided through multiple keyword argument unpackings, 
e.g. f(**{'x': 2}, **{'x': 3})
* Add some examples of dictionary overriding to the list of examples:

>>> {'x': 1, **{'x': 2}}
{'x': 2}

>>> {**{'x': 2}, 'x': 1}
{'x': 1}

* Remove "if the restrictions are kept" (they are)
* Remove "If they are removed completely..."
* In disadvantages, remove "if the current are kept" (they are).  Don't write 
"* unpackings", write "iterable unpackings"
* Remove "if the current restrictions are lifted"
* Remove "Implementation" section (it's done!)
* Add to specification: "f(*x for x in it) and f(**x for x in it)" remain 
SyntaxErrors.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Fixed a bug and added a test.

--
Added file: http://bugs.python.org/file37921/starunpack27.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 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.diff
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Changes by Neil Girdhar :


Added file: http://bugs.python.org/file37876/starunpack22.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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.org/file37867/starunpack20.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 for x in y})`.

I see your reasoning, but I don't like how your version has

 (x for y in z for x in y) ==  (*y for y in z)
f(x for y in z for x in y) != f(*y for y in z)

This seems like a tripping point. I've never wanted to unpack a 2D iterable 
into an argument list, so personally I'm not convinced by the value-add either.

--
Added file: http://bugs.python.org/file37866/starunpack19.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 now let's consider:

  f(*x for x in ['ab', 'cd'])

I personally expected this to be equivalent to:

  f(*'ab', *'cd')

IOW:

  f('a', 'b', 'c', 'd')

However, it seems your current patch (#18) interprets it as still passing a 
single argument which is the generator expression (*x for x in ['ab', 'cd']) 
which in turn is equivalent to iter(['a', 'b', 'c', 'd']), IOW f() is called 
with a single argument that is a generator.

The PEP doesn't give clarity on what to do here.  The question now is, should 
we interpret things like *x for x in ... as an extended form of generator 
expression, or as an extended form of *arg?  I somehow think the latter is more 
useful and also the more logical extension.

My reasoning is that the PEP supports things like f(*a, *b) and it would be 
fairly logical to interpret f(*x for x in xs) as doing the *x thing for each x 
in the list xs.

I think this same interpretation works for [*x for x in xs] and {*x for x in 
xs}, and we can also extend it to ** in {} and in calls (obviously ** has no 
meaning in list comprehensions or generator expressions).

BTW I think I found another bug in patch #18:

  >>> {**1}
  1
  >>> 

That should be an error.

An edge case I'm not sure about: should {**x} accept an iterable of (key, 
value) pairs, like dict(x)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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))
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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( {**x for x in l} )?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

>>> def f(a, *b): print(list(a), list(b))

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

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 in ['abc', 'def'])
> ^
> SyntaxError: invalid syntax
>
> Should neither work?  Both?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 **kwargs, though; what matters is mostly avoiding extra copies. I 
guess a few `timeit`s will show whether I'm right or totally off-base.

Most of what's needed for the error stuff is already implemented; one just 
needs to set the top bit flag (currently just 1<<8) to "1 + 
arg_count_on_stack()", which is a trivial change. I'll push a patch for that 
after I'm done fiddling with the unification idea.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Chris Angelico]

Changes by Chris Angelico :


--
nosy:  -Rosuav

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Dict comprehensions work.

--
Added file: http://bugs.python.org/file37852/starunpack16.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Dict displays work.

--
Added file: http://bugs.python.org/file37851/starunpack15.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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')
  6 LOAD_CONST   1 (1)
  9 LOAD_CONST   1 (1)
 12 LOAD_CONST   2 ('x')
 15 BUILD_MAP1
 18 LOAD_CONST   3 (2)
 21 LOAD_CONST   2 ('x')
 24 BUILD_MAP1
 27 BUILD_MAP_UNPACK 2
 30 CALL_FUNCTION_KW   256 (0 positional, 1 keyword pair)
 33 RETURN_VALUE
>>> f(y=1, **{'x': 1}, x=2)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: () got multiple values for keyword argument 'x'
>>>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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   1 (1)
 12 LOAD_CONST   0 ('x')
 15 BUILD_MAP1
 18 CALL_FUNCTION_KW   256 (0 positional, 1 keyword pair)
 21 RETURN_VALUE

There's no call to BUILD_MAP_UNPACK at all. Namely, it's raised from 
update_keyword_args (in turn from ext_do_call).


--- Tangential note: ---

In fact, it seems the only reason we keep the mess of unpacking in two places 
rather than just using BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK unconditionally 
is that CALL_FUNCTION_XXX looks to be slightly more efficient by only dealing 
with the case of a single unpack at the end. I think I see how to make the 
_UNPACKs fast enough for this case, though, so maybe we could remove it and 
unify a few things. I'd need to write it up, though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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' by name.  Is that not the error message you're 
trying to fix?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

Joshua Landau added the comment:

Just before any arguments to the function.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

when does that get pushed on the stack?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

Joshua Landau added the comment:

The function object that's on the stack.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 'arg'
   

To do this from the UNPACK opcode would require knowing where the function is 
in order to print its name. (We also need to know whether to do the check at 
all, so we'd be hijacking some bits the UNPACK opcode anyway.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 + num_maps));
}
}

This code should be relatively quick, in an already-slow opcode, and rather 
short.

If adding to CALL_FUNCTION_XXX, you would have to add an EXTENDED_ARG opcode 
(because CALL_FUNCTION_XXX already uses the bottom 16 bits), add checks for the 
top bits in the opcode, duplicate the (large) dictionary merging function. This 
doesn't seem like it saves much work.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

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 removed would be far dwarfed by the 
unpacking code in CALL_FUNCTION_XXX.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Joshua Landau]

Joshua Landau added the comment:

Why would that simplify things?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com