[issue2292] Missing *-unpacking generalizations

2017-02-11 Thread 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

2016-03-11 Thread 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

2015-12-28 Thread 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

2015-08-05 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-08-04 Thread Yury Selivanov

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-07 Thread 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 rep...@bugs.python.org
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 rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-05-07 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-07 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-07 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-06 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-06 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread 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 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 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 rep...@bugs.python.org
 wrote:


 Benjamin Peterson added the comment:

 It certainly would be nice to have documentation.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___




 --
 --Guido van Rossum (python.org/~guido)


--

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread 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 rep...@bugs.python.org
wrote:


 Benjamin Peterson added the comment:

 It certainly would be nice to have documentation.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread Berker Peksag

Changes by Berker Peksag berker.pek...@gmail.com:


--
stage: patch review - resolved

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread Guido van Rossum

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 rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread Benjamin Peterson

Changes by Benjamin Peterson benja...@python.org:


--
assignee: twouters - benjamin.peterson

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread Benjamin Peterson

Benjamin Peterson added the comment:

a65f685ba8c0

--
resolution:  - fixed
status: open - closed

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



[issue2292] Missing *-unpacking generalizations

2015-05-05 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-02 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-02 Thread Guido van Rossum

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-05-02 Thread Benjamin Peterson

Benjamin Peterson added the comment:

It certainly would be nice to have documentation.

--

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



[issue2292] Missing *-unpacking generalizations

2015-04-28 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-04-28 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-04-15 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-04-15 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-04-07 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-20 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-20 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-17 Thread Brett Cannon

Changes by Brett Cannon br...@python.org:


--
priority: normal - release blocker

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



[issue2292] Missing *-unpacking generalizations

2015-03-12 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-09 Thread Ethan Furman

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-08 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-03-05 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-26 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-24 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-09 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-03 Thread Ethan Furman

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 mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-02 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-02 Thread Ethan Furman

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-02 Thread Ethan Furman

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-02 Thread Terry J. Reedy

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-02-02 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread 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 rep...@bugs.python.org 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 rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread Éric Araujo

Changes by Éric Araujo mer...@netwok.org:


--
nosy:  -eric.araujo

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



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-30 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-29 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-29 Thread 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 rep...@bugs.python.org
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 rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-01-28 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-28 Thread 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 stdin, line 1, in module
parser.ParserError: Expected node type 12, got 302.

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 stdin, line 1
f(**i for i in ['abc', 'def'])
^
SyntaxError: invalid syntax

Should neither work?  Both?

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Guido van Rossum

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
 f(**i for i in ['abc', 'def'])
 ^
 SyntaxError: invalid syntax

 Should neither work?  Both?

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 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 Girdhar rep...@bugs.python.org wrote:


 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
 ___



--

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



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org wrote:


 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
 ___


--

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



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-26 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread 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 18) 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread Chris Angelico

Changes by Chris Angelico ros...@gmail.com:


--
nosy:  -Rosuav

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



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-25 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar

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, b, c) is (*x for x in [a, b, c])
itertools.chain.from_iterable(it) is (*x for x in it)

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Joshua Landau

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

https://docs.python.org/3/library/dis.html#opcode-EXTENDED_ARG

This could be used by BUILD_MAP rather than falling back to BUILD_MAP_UNPACK.

- It's probably best to not include it here, since it's a disjoint issue. This 
patch wouldn't really be affected by its absence.

Also, if we limit BUILD_MAP_MERGE to 255 dictionaries, this will also apply to 
the {**a, **b, **c, ...} syntax, although I really can't see it being a problem.

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Giampaolo Rodola'

Changes by Giampaolo Rodola' g.rod...@gmail.com:


--
nosy:  -giampaolo.rodola

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Joshua Landau

Joshua Landau added the comment:

Why would that simplify things?

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Joshua Landau

Joshua Landau added the comment:

The function object that's on the stack.

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Neil Girdhar

Neil Girdhar added the comment:

when does that get pushed on the stack?

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread Joshua Landau

Joshua Landau added the comment:

Just before any arguments to the function.

--

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



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2292] Missing *-unpacking generalizations

2015-01-22 Thread 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 rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   >