[Python-ideas] Yet More Unpacking Generalizations (or, Dictionary Literals as lvalues)

[Andrew Barnert]

On Aug 12, 2015, at 11:44, Scott Sanderson <scoutoss at gmail.com> wrote:

>> I think that anything that is only needed "occasionally" doesn't have a 
>> strong claim to deserve syntax. 
> 
> I suppose I might have worded this more strongly.  I meant "occasionally" to be interpreted as "often enough that I've been irked by not having a cleaner way to express this construct"

Personally, I've been irked by not having a way to express generalized pattern matching more often than I've been irked by the fact that the limited pattern matching doesn't include dicts (to the point that my reasonable thorough but not seriously proposed idea for pattern matching didn't even the obvious way to fit dicts into the system and I didn't notice until someone else pointed it out). I don't know if that's because we're writing different code, or if I spend more time coming back to Python code with my brain still halfway on another language, or just what we find natural... Personally, I'd still rather have full pattern matching (including a protocol roughly akin to copy/pickle to let arbitrary types participate in matching), but I can see why others might find the special case more useful than the general one.

As for nested dicts assignment (or nested dicts and tuples), my first reaction was that you're building something very complicated but still very limited if it can handle fully general nesting of mappings and sequences but can't handle any other kind of containment. But then I realized that the exact same thing is true of JSON, and that's turned out to be pretty useful. When I use YAML, I make lots of use of things like having datetimes as a native type, but use other kinds of containers (I think I've used a multidict extension once...). So maybe my gut reaction here is wrong.

> locals() is not writable, as you point out, in function calls.  However, I'm not sure that having a mutable locals is a good solution to this problem.  As mentioned in the original post, I most often want to do this in contexts where I'm unpacking serialized data, in which case it's probably not a great idea to have that data trample your namespace with no restrictions.

What about exposing LocalsToFast to the language? Then, in the rare cases where you do want to mutate locals, you make it explicit--and it's also much more obvious that you have to name the variables somewhere and that you're potentially pessimizing the code.

>> More practical, and in the spirit of tuple unpacking: 
>>     spam, eggs, cheese = **expression
> 
> I like how concise this syntax is.  I'd be sad that it doesn't allow unpacking of nested expressions, though I think we disagree on whether that's actually an issue.
> A more substantial objection might be that this could only work on mapping objects with strings for keys.

The same substantial objection applies to the existing uses of **, both in passing a dict as keyword arguments and in capturing unbound keyword arguments. So, for example, you can't really pass a dict through a function call by passing and accepting **kw, and c = dict(a, **b) doesn't really merge two dicts--and yet it's still useful for that purpose in many cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150812/0e6446f5/attachment.html>