Then is it too late to point out that the desired goal (of dumping part of a dict into the local namespace) is really similar to importing? Something I am most definitely not suggesting: from some_dict dict_import a, b, c Related, a version that works for Enums: from some_Enum attr_import * from vars(some_enum) dict_import * Again, I'm not suggesting these syntaxes (and I hope everyone else hates them), just pointing out that it's more similar to imports than destructuring. On Wed, May 25, 2016 at 11:46 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 05/25/2016 07:56 PM, Chris Angelico wrote:
On Thu, May 26, 2016 at 12:43 PM, Ethan Furman wrote:
I'll meet you halfway:
{a, b} = some_dict
which is currently a SyntaxError, so little backwards compatibility concerns, plus it clearly state the mapping should have two elements, similarly to
[a] = some_iterable
and
(b) = some_iterable
both clearly state that a one-element iterable is being unpacked.
Careful - the second one doesn't:
--> (b) = [1, 2, 3] -->
Ack. Right you are, which is why I always use the list form, even on tuples.
I hope there doesn't end up being a confusion between mapping unpacking and set display. Sets are a bit of an odd duck; are they like lists only unordered, or like mappings only without values? I've seen them used both ways, and the syntax is somewhere between the two. Having a syntax that constructs a set if used on the RHS but unpacks a dict if used on the LHS seems to violate syntactic purity, but I'd be happy to let practicality trump that.
Given the other issues, I'm happy to let this one die. Good discussion.
-- ~Ethan~
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/