[Python-ideas] PEP for issue2292, "Missing *-unpacking generalizations"

[Oscar Benjamin]

On 15 July 2013 21:06, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jul 15, 2013 at 1:01 PM, Oscar Benjamin
> <oscar.j.benjamin at gmail.com> wrote:
>> On 15 July 2013 12:08, Joshua Landau <joshua.landau.ws at gmail.com> wrote:
>>> On 15 July 2013 11:40, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
>>>
>>> In fact, I'd much like it if there was an iterable "unpacking" method
>>> for functions, too, so "chain.from_iterable()" could use the same
>>> interface as "chain" (and str.format with str.format_map, etc.). I
>>> feel we already have a good deal of redundancy due to this.
>>
>> I've also considered this before. I don't know what a good spelling
>> would be but lets say that it uses *args* so that you have a function
>> signature like:
>>
>>     def chain(*iterables*):
>>        for iterable in iterables:
>>             yield from iterable
>>
>> And then if the function is called with
>>
>>     for line in chain(first_line, *inputfile):
>>         # do stuff
>>
>> then iterables would be bound to a lazy generator that chains
>> [first_line] and inputfile. Then you could create the unpacking
>> iterator I wanted by just using chain e.g.:
>>
>>     chain(prepend, *iterable, append)
>
> But how could you do this without generating different code depending
> on how the function you are calling is declared? Python's compiler
> doesn't have access to that information.

Good point. Maybe you'd have to spell it that way at both ends:

    chain(prepend, *iterable*, append)


Oscar