On Apr 16, 2020, at 20:48, [email protected] wrote:
>
> In Javascript ES6 they don't have sets built like python so `{}` always
> refers to objects being constructed. It does indeed support implicit key:
> value pairs, so in ES6 `{ a: a, b: x, c: c }` is equivalent to `{ a, b: x, c
> }`. This is okay for Javascript users because they would not thought it as
> sets and the only obvious assumption to make is that parameters are being
> implicitly assigned to members. This is not the case in Python so I would
> refrain from changing dictionary literals syntax.
Obviously the exact same syntax as ES6 doesn’t work in Python, because it would
be not just confusing but ineradicably ambiguous with sets.
But I don’t see why that rules out the “bare colon” form that I and someone
else apparently both proposed in separate sub threads of this thread:
{ :a, "b": x, :c }
as shorthand for:
{ "a": a, "b": x, "c": c }
There’s no problem for the parser. Make a trivial change to the grammar to add
a `":" identifier` alternative to dict display items, and nothing becomes
ambiguous.
And I don’t think it would be confusing to a human reader. It can’t possibly be
a set, because colons are what make a dict display not a set display, and there
are colons.
And I think extending dict display syntax is more powerful and less disruptive
than extending call syntax. It means you can refactor the {…} in a **{…} if the
call gets too unwieldy; it means calls and other places with ** unpacking
remain consistent; etc.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/IEPZ7WBQC6FOG3IYHGQV4IJEZUBJHSUO/
Code of Conduct: http://python.org/psf/codeofconduct/
