If you find PEP-634 a bit dry, you might give a try to PEP-636 (written in
an explanatory style rather than a hard-spec style). You can always go back
to PEP-634 for the precise details.
On Fri, 23 Oct 2020 at 13:48, Ricky Teachey <ri...@teachey.org> wrote:
> Fwiw, although I see how PEP 634 has the potential to be incredibly
> powerful and I'm not opposed to it, I've tried to read and understand it
> twice and it is so overwhelming I still find the syntax inscrutable (I'm
> sure I'll get it eventually). I think Steven's proposed idea has a lot of
> merit even in a post PEP 634 universe because the syntax is just so easy to
> understand right away. At least for me.
>
> Pattern matching seems like it will fall under a learn python course
> section titled "advanced python topics". Dict unpacking is more of a
> moderate python topic.
>
> Additionally, Alex Hall's suggestions for how to use the various proposals
> for shortened dict display syntax, bringing Steven's proposal in line with
> pattern matching syntax but not having to repeat key names, is a really
> nice reconciliation of the too syntax ideas.
>
> And it would also allow something like this:
>
> {spam, eggs, 'def': def_, 'class': class_, **kwargs} = kwargs
>
> ...fixing the name collision problem.
>
> On Fri, Oct 23, 2020, 5:41 AM Alex Hall <alex.moj...@gmail.com> wrote:
>
>> On Fri, Oct 23, 2020 at 11:10 AM Steven D'Aprano <st...@pearwood.info>
>> wrote:
>>
>>> > but that doesn't make it make sense to write `... = **values` as you
>>> > suggest.
>>>
>>> Iterator unpacking on a dict already works:
>>>
>>> py> d = {'a': 10, 'b': 20}
>>> py> spam, eggs = d
>>> py> spam, eggs
>>> ('a', 'b')
>>>
>>> so we need to distinguish the iterator unpacking case from the dict
>>> unpacking case.
>>
>>
>> I understand that, I just don't think this particular method of
>> distinguishing is sufficiently justified.
>>
>> (Heretical question: do we *really* need to distinguish it in syntax?
>> Iterator unpacking a dict seems like a dumb idea, I wouldn't be sad if we
>> broke compatibility there)
>>
>> To me it makes sense to use the same double star used in
>>> dict unpacking inside dict displays and function calls.
>>>
>>
>> It makes some sense, but overall it's still quite different to anything
>> existing. Typically the mechanics of assignment are defined by symbols that
>> come before the =. This applies to iterable unpacking, setting attributes
>> and mapping items, and augmented assignment. Everything after = just a
>> normal expression.
>>
>> The most obvious syntax is to just assign to a dict display:
>>
>> {'spam': spam, 'eggs': eggs, **kw} = kwargs # not **kwargs
>>
>> The meaning seems intuitive and obvious at a glance. And it's flexible if
>> the variable names don't always match the keys. But it's verbose and
>> repetitive in the common case where the names match.
>>
>> I think it would be great if we had a syntax for abbreviating normal
>> dicts with 'same name' keys. We discussed a lot of options earlier this
>> year, e.g:
>>
>> {**, spam, eggs}
>> {:spam, :eggs}
>> {{spam, eggs}}
>>
>> Then using the same syntax in both dict unpacking and dict displays as
>> expressions would be intuitive and obvious. This would be valid, although
>> redundant:
>>
>> {**, spam, eggs} = {**, spam, eggs}
>>
>> and it would still be easy to add cases where names don't match:
>>
>> {'sleep': duration, **, spam, eggs} = kwargs
>>
>> Also, unpacking nested dicts follows naturally, whether we have an
>> abbreviated syntax or not:
>>
>> {'spam': {'eggs': eggs, 'foo': foo}, 'bar': bar} = {'spam': {'eggs':
>> eggs, 'foo': foo}, 'bar': bar}
>>
>> As does unpacking in a loop:
>>
>> for {**, spam, eggs} in list_of_dicts:
>>
>> whereas I'm not sure what would be done in your proposal. Something like
>> this?
>>
>> for spam, eggs in **list_of_dicts:
>> _______________________________________________
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/SNYIR4IUSTYYH6IQNMCQ5SUTORDPILO6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/FK3A7XBCIRFGZCSBHF5NM2JVEURXCAV3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QXGWSL4F7WCVFCXQLAMRLN3ZMQHOJRKX/
Code of Conduct: http://python.org/psf/codeofconduct/
