One reason MRAB points to. The `*keys` syntax is more-or-less equivalent to "substitute a tuple" in other Python contexts; you are proposing to give it a completely different meaning. This would be confusing and inconsistent.
I disagree that it is a completely different meaning. If the issue is that f(1,2,3) is the same as f(*(1,2,3)), but d[1,2,3] wouldn't be the same as d[*(1,2,3)], that's only because the "1,2,3" in d[1,2,3] already means something very different than the "1,2,3" in f(1,2,3). If we don't cheat by comparing expressions to expression lists, the two are fairly analogous. `f(t)` means pass the tuple to the function, and `d[t]` means use the tuple as a key. `f(*t)` means break up the tuple and pass each element as an argument to the function, and `d[*t]` means break up the tuple and pass each element to getitem in turn. I could see it as somewhat confusing, but I don't agree it's particularly inconsistent. It's not exactly the same, of course, because we're invoking getitem several times on different objects, rather than once with multiple arguments, but that's only because you can't pass multiple arguments to getitem, even if you wanted to invoke it directly rather than using square brackets, because it only takes one argument (or two, if you want to count self).
However, let's bracket the syntax for a moment. More important is that "nested" data comes in shapes other than strictly nested dictionaries. This seems to be most common in dealing with JSON data, but in concept it can arise elsewhere. A variety of libraries address this, with some small differences among them. Many are inspired by the semi-convention of "JSON Path" that is inspired by XPath for XML.
For example, what if our data looks like this:
data = {1: [{2: {3, 4}}, {5: {6,7}}, [8, 9, 0]]}
I'm sorry, but I don't really see how this presents an issue to what I suggested, beyond simply that you wouldn't be able to access individual elements of the sets (because sets themselves don't support getitem). For example, if you wanted to access the 9, you would do: d[1][-1][1] Which in my proposed syntax would be: d[*(1, -1, 1)] --- What initially sparked this suggestion was an issue where I had to find the maximum value in a nested list (where sublists could themselves contain sublists, but potentially might not), and modify it to something else. My initial solution was basically to walk through the list, and keep a list of all the indices to get to the currently found maximum. Then, once that's done, use the list of indices to modify what is now known to be the true maximum. I ended up writing a nested_setitem function since that sort of operation isn't natively supported. Admittedly, I changed it afterwards so that the loop instead stored the sublist the maximum was found in and only the index in that sublist, eliminating the need for nested_setitem, so even in the problem I was working on, I wouldn't have ended up using my own proposed syntax... So it might not actually be useful, after all.