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 <me...@gnosis.cx> wrote: > On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine <jfine2...@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). >
_______________________________________________ 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/62Y7TQXAMH2HCJPRCZOBHVHQJ76IBG4O/ Code of Conduct: http://python.org/psf/codeofconduct/
