Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be useful for xarray, but I'm not sure now what that would look like. If someone had an example, I could easily be moved.

I'm not against the original suggested use with type annotations, but I also don't really care about it. I don't think 'd[K(1, 2, 3, a=4, b=5)]' is bad as an existing spelling.

On Fri, Jul 17, 2020, 12:08 PM David Mertz <mertz@gnosis.cx> wrote:
On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine <jfine2358@gmail.com> wrote:
Steve and I have different opinions, as to what the new behaviour of:
    >>> d = dict()
    >>> d[x=1, y=2] = 3
should be.

He prefers that the assignment fail with
    TypeError: dict subscripting takes no keyword arguments

I prefer that the assignment succeed (and hence a new key-value pair is added to 'd').

I definitely agree with Steven. It is obviously *possible* to create some brand new type of object that is "multi-assignment fragment." But why?!

No clearly useful semantics comes to mind for this new object. Well, it would need to be hashable. Lots of things are though, so it's not like we have nothing to use as dict keys now.

We don't lose anything if we add the feature but intake don't support it for dictionaries. If someone comes up with a really useful reason to have that MultiAssignmentType, is not usually considered a breaking change to go from "this raises am exception" to "this does something worthwhile" (but obviously, in all such cases, you can artificially construct code that will break without a certain exception).