I think Guido has given a direct answer why dict unpacking is not supported
in syntax level,
I can take it and I think it's better to implement a function for dict
unpacking in standard library, just like
from dict_unpack import dict_unpack, pattern as pat
some_dict = {'a': {'b': {'c': 1}, 'd':2}, 'e': 3}
extracted = dict_unpack(some_dict, schema = {'a': {'b': {'c':
pat('V1')}, 'd': pat('V2')}, 'e': pat('V3')})
# extract to a flatten dictionary
v1, v2, v3 = (extracted[k] for k in ('V1', 'V2', 'V3'))
assert (v1, v2, v3) == (1, 2, 3)
As for Steve's confusion,
> > {key: value_pattern, **_} = {key: value, **_}
> If I saw that, I would have no idea what it could even possibly do.
> Let's pick the simplest concrete example I can think of:
>
> {'A': 1, **{}} = {'A': 0, **{}}
>
> I cannot interpret what that should do. Is it some sort of
> pattern-matching? An update? What is the result? It is obviously some
> sort of binding operation, an assignment, but an assignment to what?
{'A': 1, **{}} = {'A': 0, **{}} should be just wrong because for any k-v
pair at LHS, the key should be a expression and the value is for unpacking.
{'A': [*a, b]} = {'A': [1, 2, 3]} is welcome, but {'A': 1} = {'A': '1'} is
also something like pattern matching which is out of our topic.
Anyway, this feature will not come true, let's forget it...
I think Jacco is totally correct in following words.
> I think most of these problems could be solved with pop and the
> occasional list comprehension like this:
>
> a, b, c = [{'a':1,'b':2,'c':3}.pop(key) for key in ('a', 'b', 'c')]
>
> or for your example:
>
> c = {'a': 1, **{'b': 2}} # I suppose this one would generally
> # be dynamic, but I need a name here.
> a, b = [c.pop(key) for key in ('a', 'b')]
>
> would extract all the keys you need, and has the advantage that
> you don't need hardcoded dict structure if you expand it to nested
> dicts. It's even less writing, and just as extensible to nested dicts.
> And if you dont actually want to destruct (tuples and lists aren't
> destroyed either), just use __getitem__ access instead of pop.
But pop cannot work for a nested case.
Feel free to end this topic.
thautwarm
2018-04-10 23:20 GMT+08:00 <python-ideas-requ...@python.org>:
> Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
> Today's Topics:
>
> 1. Re: Is there any idea about dictionary destructing?
> (Steven D'Aprano)
> 2. Re: Is there any idea about dictionary destructing?
> (Jacco van Dorp)
> 3. Re: Start argument for itertools.accumulate() [Was: Proposal:
> A Reduce-Map Comprehension and a "last" builtin] (Guido van Rossum)
> 4. Re: Is there any idea about dictionary destructing?
> (Guido van Rossum)
>
>
> ---------- 已转发邮件 ----------
> From: "Steven D'Aprano" <st...@pearwood.info>
> To: python-ideas@python.org
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 19:21:35 +1000
> Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
> On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote:
>
> > I'm focused on the consistency of the language itself.
>
> Consistency is good, but it is not the only factor to consider. We must
> guard against *foolish* consistency: adding features just for the sake
> of matching some other, often barely related, feature. Each feature must
> justify itself, and consistency with something else is merely one
> possible attempt at justification.
>
>
> > {key: value_pattern, **_} = {key: value, **_}
>
> If I saw that, I would have no idea what it could even possibly do.
> Let's pick the simplest concrete example I can think of:
>
> {'A': 1, **{}} = {'A': 0, **{}}
>
> I cannot interpret what that should do. Is it some sort of
> pattern-matching? An update? What is the result? It is obviously some
> sort of binding operation, an assignment, but an assignment to what?
>
> Sequence binding and unpacking was obvious the first time I saw it. I
> had no problem guessing what:
>
> a, b, c = 1, 2, 3
>
> meant, and once I had seen that, it wasn't hard to guess what
>
> a, b, c = *sequence
>
> meant. From there it is easy to predict extended unpacking. But I can't
> say the same for this.
>
> I can almost see the point of:
>
> a, b, c, = **{'a': 1, 'b': 2, 'c': 3}
>
> but I'm having trouble thinking of a situation where I would actually
> use it. But your syntax above just confuses me.
>
>
> > The reason why it's important is that, when destructing/constructing for
> > built-in data structures are not supported completely,
> > people might ask why "[a, *b] = c" is ok but "{"a": a, **b} = c" not.
>
> People can ask all sorts of questions. I've seen people ask why Python
> doesn't support line numbers and GOTO. We're allowed to answer "Because
> it is a bad idea", or even "Because we don't think it is good enough to
> justify the cost".
>
>
> > If only multiple assignment is supported, why "(a, (b, c)) = d" could be
> > ok? It's exactly destructing!
>
> That syntax is supported. I don't understand your point here.
>
>
> > >> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
> > SyntaxError: can't assign to literal
> >
> > Above example could be confusing in some degree, I think.
>
> I have no idea what you expect it to do. Even something simpler:
>
> {'a': a} = {'a': 2}
>
> leaves me in the dark.
>
>
>
>
> --
> Steve
>
>
>
> ---------- 已转发邮件 ----------
> From: Jacco van Dorp <j.van.d...@deonet.nl>
> To: python-ideas@python.org
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 11:52:40 +0200
> Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
> I must say I can't really see the point either. If you say like:
>
> > {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
>
> Do you basically mean:
>
> c = {'a': 1, **{'b': 2}}
> a = c.pop("a")
> b = c.pop("b") # ?
>
> That's the only thing I could think of.
>
> I think most of these problems could be solved with pop and the
> occasional list comprehension like this:
>
> a, b, c = [{'a':1,'b':2,'c':3}.pop(key) for key in ('a', 'b', 'c')]
>
> or for your example:
>
> c = {'a': 1, **{'b': 2}} # I suppose this one would generally
> # be dynamic, but I need a name here.
> a, b = [c.pop(key) for key in ('a', 'b')]
>
> would extract all the keys you need, and has the advantage that
> you don't need hardcoded dict structure if you expand it to nested
> dicts. It's even less writing, and just as extensible to nested dicts.
> And if you dont actually want to destruct (tuples and lists aren't
> destroyed either), just use __getitem__ access instead of pop.
>
> 2018-04-10 11:21 GMT+02:00 Steven D'Aprano <st...@pearwood.info>:
> > On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote:
> >
> >> I'm focused on the consistency of the language itself.
> >
> > Consistency is good, but it is not the only factor to consider. We must
> > guard against *foolish* consistency: adding features just for the sake
> > of matching some other, often barely related, feature. Each feature must
> > justify itself, and consistency with something else is merely one
> > possible attempt at justification.
> >
> >
> >> {key: value_pattern, **_} = {key: value, **_}
> >
> > If I saw that, I would have no idea what it could even possibly do.
> > Let's pick the simplest concrete example I can think of:
> >
> > {'A': 1, **{}} = {'A': 0, **{}}
> >
> > I cannot interpret what that should do. Is it some sort of
> > pattern-matching? An update? What is the result? It is obviously some
> > sort of binding operation, an assignment, but an assignment to what?
> >
> > Sequence binding and unpacking was obvious the first time I saw it. I
> > had no problem guessing what:
> >
> > a, b, c = 1, 2, 3
> >
> > meant, and once I had seen that, it wasn't hard to guess what
> >
> > a, b, c = *sequence
> >
> > meant. From there it is easy to predict extended unpacking. But I can't
> > say the same for this.
> >
> > I can almost see the point of:
> >
> > a, b, c, = **{'a': 1, 'b': 2, 'c': 3}
> >
> > but I'm having trouble thinking of a situation where I would actually
> > use it. But your syntax above just confuses me.
> >
> >
> >> The reason why it's important is that, when destructing/constructing for
> >> built-in data structures are not supported completely,
> >> people might ask why "[a, *b] = c" is ok but "{"a": a, **b} = c" not.
> >
> > People can ask all sorts of questions. I've seen people ask why Python
> > doesn't support line numbers and GOTO. We're allowed to answer "Because
> > it is a bad idea", or even "Because we don't think it is good enough to
> > justify the cost".
> >
> >
> >> If only multiple assignment is supported, why "(a, (b, c)) = d" could be
> >> ok? It's exactly destructing!
> >
> > That syntax is supported. I don't understand your point here.
> >
> >
> >> >> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
> >> SyntaxError: can't assign to literal
> >>
> >> Above example could be confusing in some degree, I think.
> >
> > I have no idea what you expect it to do. Even something simpler:
> >
> > {'a': a} = {'a': 2}
> >
> > leaves me in the dark.
> >
> >
> >
> >
> > --
> > Steve
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> ---------- 已转发邮件 ----------
> From: Guido van Rossum <gu...@python.org>
> To: "Stephen J. Turnbull" <turnbull.stephen...@u.tsukuba.ac.jp>
> Cc: Tim Peters <tim.pet...@gmail.com>, Python-Ideas <
> python-ideas@python.org>
> Bcc:
> Date: Tue, 10 Apr 2018 08:05:18 -0700
> Subject: Re: [Python-ideas] Start argument for itertools.accumulate()
> [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]
> On Mon, Apr 9, 2018 at 11:35 PM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> Tim Peters writes:
>>
>> > "Sum reduction" and "running-sum accumulation" are primitives in
>> > many peoples' brains.
>>
>> I wonder what Kahneman would say about that. He goes to some length
>> to explain that people are quite good (as human abilities go) at
>> perceiving averages over sets but terrible at summing the same. Maybe
>> they substitute the abstraction of summation for the ability to
>> perform the operation?
>>
>
> [OT] How is that human ability tested? I am a visual learner and I would
> propose that if you have a set of numbers, you can graph it in different
> ways to make it easier to perceive one or the other (or maybe both):
>
> - to emphasize the average, draw a line graph -- in my mind I draw a line
> through the average (getting the trend for free)
> - to emphasize the sum, draw a histogram -- in my mind I add up the sizes
> of the bars
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
> ---------- 已转发邮件 ----------
> From: Guido van Rossum <gu...@python.org>
> To: Python-Ideas <python-ideas@python.org>
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 08:20:11 -0700
> Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
> Here's one argument why sequence unpacking is more important than dict
> unpacking.
>
> Without sequence unpacking, you have a long sequence, to get at a specific
> item you'd need to use indexing, where you often end up having to remember
> the indices for each type of information. Say you have points of the form
> (x, y, z, t), to get at the t coordinate you'd have to write p[3]. With
> sequence unpacking you can write
>
> x, y, z, t = p
>
> and then you can use the individual variables in the subsequent code.
>
> However if your point had the form {'x': x, 'y': y, 'z': z, 't': t}, you
> could just write p['t']. This is much more mnemonic than p[3].
>
> All the rest follows -- after a while extended forms of iterable unpacking
> start making sense. But for dicts the use case is just much less common.
>
> (If you're doing a lot of JSON you might have a different view on that.
> You should probably use some kind of schema-guided parser though.)
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
