> Why not?

What if I want a getitem that only has keyword arguments? I have to take the empty tuple as a positional argument, instead of just ensuring that the key is a dict.

> Now, assuming you want to allow ** in getitem lookups

I don't. *args are not allowed in subscripts either. However, that would make the syntax pretty much useless (in the keyword version) as indices could not be passed to a function.

While I agree, not using a keywords create a certain class of bugs, those bugs already exists. At least in the sense that if I pass a dictionary as index things are going to get weird. However, I'd rather not have all the special casing that comes with keyword arguments.

On Mon, Oct 7, 2019 at 7:57 PM Andrew Barnert <abarnert@yahoo.com> wrote:

On Oct 7, 2019, at 14:56, Caleb Donovick <donovick@cs.stanford.edu> wrote:
>
> > I think it might be better if it actually passed them as keyword arguments.
>
> If only keyword arguments are passed what happens to the positional index? Is it the empty tuple?

That seems like the obvious, and also most useful, answer.

> Currently subscript with no index (`dict()[]`) is a syntax error should it continue to be?

Why not? If you want to look up the empty tuple today, you can, you just have to be explicit: `d[()]`. This rarely comes up, but when it does, this reads pretty obvious (especially given that when people are using tuples as dict keys, they usually wrap them in parens anyway, even if it’s not necessary, because it looks clearer). I don’t see any reason to change that.

Now, assuming you want to allow ** in getitem lookups, this would add another way to write the same thing: `d[**{}]`. I suppose this should be legal (since it could easily come up with a dynamic `d[**kw]` when there happen to be no keywords), but I don’t think anyone will ever be tempted to write it, and I don’t think anyone would be confused for more than a few seconds if they did, and I don’t think that allowing it requires us to start allowing `d[]`. That’s a restriction on the syntax for readability, not a limitation on the semantics, and the same readability issue still applies.

> > 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.
>
> I had not thought about this. I have a lot of code in the form:
> ```
> if not isinstance(key, iterable):
> key = key,
> # do stuff assuming key is an iterable
> ```
> Which would have very strange behavior if a dict was passed.

Exactly. And I think what you want to happen here is a `TypeError: Spam.__getitem__ takes no keyword arguments` or similar, not treating the keywords as an iterable and ignoring their values. That’s why I think passing kwargs separately rather than just making key a dict might make more sense.

But then I haven’t put a huge amount of thought into this. Given that there’s an existing abandoned PEP, I’ll bet this was already hashed our in more detail, and you probably want to go back to that, come up with answers to the objections and open questions, and start over