[Python-ideas] Unpacking a dict

Nikolaus Rath Nikolaus at rath.org
Fri May 27 14:07:59 EDT 2016

On May 27 2016, Ethan Furman <ethan-gcWI5d7PMXnvaiG9KC9N7Q at public.gmane.org> wrote:
> On 05/27/2016 08:09 AM, Nikolaus Rath wrote:
>> On May 26 2016, Paul Moore wrote:
>>> On 26 May 2016 at 18:55, Ethan Furman wrote:
>>>> With the simple syntax that I could live with, a real example could be:
>>>>    {active_id, active_ids, active_model} = context
>>>> or
>>>>    {partner_id, product_id, ship_to, product_ids} = values
>>> The behaviour of using the names of the variables from the LHS to
>>> introspect the value on the RHS is, to me, extremely magical and
>>> unlike anything I've seen in any other language. I don't think it sits
>>> well in Python, even though it is certainly a very readable idiom for
>>> the sort of unpacking we're talking about here.
>> Very true. But as someone else already said (I can't find the email
>> right now), we have a different construct that everyone is familiar with
>> and that's easily adapted for this situation:
>> from dict context import active_id, active_ids, active_model
>> or more general:
>> "from dict"  <expr> "import" <identifier list>
>> Everyone knows that "from .. import .." modifies the local namespace. We
>> just have to extend it to work not just on modules, but also on
>> dictionaries.
> -1
> import works with modules.

You don't think of it as "*import*ing something from another namespace
into the local namespace"? That's the first thing that I associate with

> Having it work with other things would
> muddy the concept, plus make module/object naming conflicts an even
> bigger hassle.

You did see that I proposed "from dict <> import ..", instead of "from
<> import ..", right? The latter would continue to work only for
modules. The form would be new syntax and only work for dicts.


GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

More information about the Python-ideas mailing list