[Python-ideas] iterable.__unpack__ method

[Jan Kaliszewski]

On 23.02.2013 19:19, Masklinn wrote:

> On 2013-02-23, at 12:58 , Nick Coghlan wrote:
[...]
>> - for function parameter unpacking, would we allow "*args" to be an
>> arbitrary iterable rather than promising that it is always a tuple? 
>> We
>> would probably want to do so for consistency with unpacking 
>> assignment
>> under this scheme, which may lead to some confusing error messages
>> thrown by existing functions which expect it to always be a tuple.
>
> I don't think so, they already have a significant semantic split on
> the meaning of what follows an *args, and I've got the gut feeling
> that *args being a tuple is a much more common assumption/expectation
> for functions than for unpacking (especially since *args in unpacking
> was only introduced in Python 3)

Especially that for unpacking it is *a list, not a tuple*.
  and
Cheers.
*j

PS. And would it be really possible to apply the __unpack__-idea to 
calls?
There had not been and still there is no real consistency between 
unpacking
and call argument binding, e.g.

     def fun(a, b, c, *args):
         ...
     fun(1, 2, with_dunder_unpack)

     # ^ OK: a = 1; b = 2; c, *args = with_dunder_unpack
     # but what about:

     def fun(a, b, c, *args):
         ...
     fun(1, 2, 3, 4, 5, with_dunder_unpack)

     # ^ a = 1; b = 2; c = 3; args = ???

I believe these concepts (unpacking and call argument binding) are 
simply not
really parallel in Python.

Yes, `a, b, *seq` in unpacking is *somehow* similar -- on the level of 
a rough
intuition (and that is nice) but IMHO it should not stop us from 
extending
unpacking without worrying much about call binding which was, is and 
must be
(in Python) different in many ways.