On Thursday, May 26, 2016, Steven D'Aprano <steve@pearwood.info> wrote:
I think this is important enough to get a change in subject line, lest
it be lost in the dict unpacking thread.


On Thu, May 26, 2016 at 11:28:25PM +0100, Nathan Schneider wrote:

> Instead of special syntax, what if dict.values() returned a tuple when
> given keys as arguments:
>
>    partner_id, product_id, ship_to, product_ids = my_dict.values(
>            'partner_id', 'product_id', 'ship_to', 'product_ids')
>
> That avoids repeating the dict variable, at least. And as there is
> dict.update(), I don't see the need for a new syntax for assigning to
> multiple keys.

I like this idea. I think it beats the status quo:

partner_id = my_dict['partner_id']
product_id = my_dict['product_id']
# etc.

and the various "dict unpacking" syntax suggested, e.g.:

{'partner_id': partner_id, 'product_id': product_id, **catch_all} = my_dict


and it's less magical than variants that extract the names from the left
hand side:

partner_id, product_id, ship_to, product_ids = **my_dict

It naturally and trivially supports the case where assignment targets
aren't names, and where keys are not identifiers:

obj.partner_id, products[the_id] = my_dict.values('partner id', 'is')

It's still a bit repetitive in the simple case where the keys are the
same as the variable names, but without compiler magic, what else are
you going to do?

+1

Interesting. It should probably have a different name. What type should it return? Iterator? Sequence? It can't really be a ValuesView because that class is just a view on the hash table. Even though you technically *could* combine this functionality into values(), I don't think it would be helpful to do so -- if only because of the surprising edge case where if you were to pass it a list of keys to extract using **args, if the list is empty, values() would default to its original behavior or returning all keys, in hash table order.

--Guido