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/
