PEP 646: Explain the results of the new grammar/compiler change

[mrahtz]

@pradeep90 @gvanrossum @stroxler

I'm still not entirely sure that having the compiler emit the equivalent of next(iter(Ts)) for *args: *Ts is the best solution. The alternatives I can think of are:

1. [*Ts][0] (uglier, but the bytecode ends up being a little simpler)
2. Directly accessing the property Ts._unpacked (less ugly, but less consistent with other uses of the star operator)

Having said that, I also think next(iter(Ts)) is Good Enough (tm) - and in the first place (I think?) it's not too critical an issue because it's an implementation detail. So happy to discuss this, but also happy not to discuss this :)

[TeamSpen210]

Looking at the bytecodes, you could use UNPACK_SEQUENCE with an arg of 1 on its own to do the operation. It'll verify the iterator is exhausted too afterward as a bonus, unlike next(iter(Ts)).

[stroxler]

This looks good to me, especially if we follow @TeamSpen210's suggestion - it seems handy to verify that only length-1 iterators are ever used this way.

You're right that it's an implementation detail as long as the AST and visible behavior are nailed down, so if reviewers of the cpython code have other ideas that should also be okay.

We should be able to use the same approach for unpacking in callable syntax.

[mrahtz]

Thanks for the excellent suggestion, @TeamSpec210! I've switched to UNPACK_SEQUENCE in mrahtz/cpython@81a7327 and it works like a charm :)

And thanks, Guido, for the feedback! I've made the changes you suggested.

[gvanrossum]

LGTM. I will merge now!