The primary issue I was trying to find a way to reliably and clearly avoid conflicts between the index labels and the positional argument names.  So if you have:

__getitem__(self, index, **kwargs)

You can't have an index label named "index", because it conflicts with the "index" positional argument.

Apparently that isn't an issue if you structure it like this instead:

__getitem__(self, index, /, **kwargs)

But projects would need to know to do that.

Also, as Greg alluded to, it is more consistent with how the indices are handled currently, which is to use a single variable rather than positional arguments.  There may also be performance implications, although I am not certain about that.

On Mon, Aug 3, 2020 at 9:36 PM Steven D'Aprano <> wrote:
On Mon, Aug 03, 2020 at 05:20:25PM -0400, Todd wrote:
> Another approach could be too simply pass the labelled indices in a dict as
> a third/fourth positional argument.

Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods, `__getitem__`,
`__setitem__` and `__delitem__`, instead of handling keyword arguments
in the same way that every other method handles them?

That's not a rhetorical question. If there is an advantage to making
this a special case, instead of just following the same rules as all
other methods, I'm open to hearing why it should be treated as a special

> So for indexing
> b = arr[1, 2, a=3, b=4]
> Instead of
> __getitem__(self, (1, 2), a=3, b=4)
> Just do
> __getitem__(self, (1, 2), {'a': 3, 'b': 4})

That would be the effect of defining your method with signature:

    def __getitem__(self, index, **kwargs)

so if you specifically want all your keyword arguments bundled into a
dict, you can easily get it.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: