
On Oct 4, 2019, at 12:34, Caleb Donovick <donovick@cs.stanford.edu> wrote:
Allowing key value pairs in geitem need not change the interface of getitem. All the key value pairs could be collected as a dict and passed to getitem as the index. Similar to how the all the positional arguments are gather into a single tuple. ``` class Foo: def __getitem__(self, idx): print(idx)
f = Foo() f[x=1, y=2] # {'x': 1, 'y': 2} ``` This would make any legacy code using normal dicts as keys (I don't know how prevalent that is) automatically work with the new syntax.
There doesn't necessarily need to be support for mixing of tuple based indexing and keyword indexing. i.e. ``` obj[0, x=1] # SyntaxError
I think it might be better if it actually passed them as keyword arguments. Then, using the syntax with existing objects would raise a TypeError saying that the type doesn’t take keyword arguments, instead of saying that dict can’t be converted to an int or something else less clear. Also, I think there are user implementations that accept any iterable, whether to treat it as a tuple or as an array-like, and a dict is an iterable of its keys, so it might do the wrong thing rather than raising at all. It would be a bit weird that what look like positional arguments are actually a tuple, but what look like keyword arguments are keyword arguments, but I don’t think that’s too bad. Maybe it would help if you showed a realistic __getitem__ that did the existing type-switching to handle slice, ellipsis, thing with __index__, or tuple of the above, and then also did the switching on dict or also took **kwargs. I suspect that either way, it would turn out that most of the complexity is due to the existing complicated interface of __getitem__ and keywords don’t make it much different. But I’m not sure that would be true. And I think many of the objections are from people who suspect the opposite.