<div dir="ltr"><div>On Thursday, May 26, 2016, Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think this is important enough to get a change in subject line, lest<br>
it be lost in the dict unpacking thread.<br>
<br>
<br>
On Thu, May 26, 2016 at 11:28:25PM +0100, Nathan Schneider wrote:<br>
<br>
> Instead of special syntax, what if dict.values() returned a tuple when<br>
> given keys as arguments:<br>
><br>
>    partner_id, product_id, ship_to, product_ids = my_dict.values(<br>
>            'partner_id', 'product_id', 'ship_to', 'product_ids')<br>
><br>
> That avoids repeating the dict variable, at least. And as there is<br>
> dict.update(), I don't see the need for a new syntax for assigning to<br>
> multiple keys.<br>
<br>
I like this idea. I think it beats the status quo:<br>
<br>
partner_id = my_dict['partner_id']<br>
product_id = my_dict['product_id']<br>
# etc.<br>
<br>
and the various "dict unpacking" syntax suggested, e.g.:<br>
<br>
{'partner_id': partner_id, 'product_id': product_id, **catch_all} = my_dict<br>
<br>
<br>
and it's less magical than variants that extract the names from the left<br>
hand side:<br>
<br>
partner_id, product_id, ship_to, product_ids = **my_dict<br>
<br>
It naturally and trivially supports the case where assignment targets<br>
aren't names, and where keys are not identifiers:<br>
<br>
obj.partner_id, products[the_id] = my_dict.values('partner id', 'is')<br>
<br>
It's still a bit repetitive in the simple case where the keys are the<br>
same as the variable names, but without compiler magic, what else are<br>
you going to do?<br>
<br>
+1<br></blockquote><div><br>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. <br></div>
<br></div>--Guido<br></div>