[Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments

Eric Wieser wieser.eric+numpy at gmail.com
Fri Sep 25 10:22:13 EDT 2020


I agree with Stephan's suggestion of having no default value for positional
indices, and letting the user supply it.

It seems I replied badly to the mail on the python-ideas list, and my
response ended up as a separate thread, at
https://mail.python.org/archives/list/python-ideas@python.org/thread/ZQ4CHT37YUHYEFYFBQ423QNZMFCRULAW/
.

Eric

On Thu, 24 Sep 2020 at 22:22, Aaron Meurer <asmeurer at gmail.com> wrote:

> This PEP also opens the possibility of allowing a[] with nothing in the
> getitem. Has that been considered?
>
> Aaron Meurer
>
> On Thu, Sep 24, 2020 at 1:48 PM Sebastian Berg <sebastian at sipsolutions.net>
> wrote:
>
>> On Wed, 2020-09-23 at 21:41 -0700, Stephan Hoyer wrote:
>> > On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini <
>> > stefano.borini at gmail.com>
>> > wrote:
>>
>> <snip>
>>
>> > >
>> > Hi Stefano -- thanks for pushing this proposal forward! I am sure
>> > that
>> > support for keyword indexing will be very welcome in the scientific
>> > Python
>> > ecosystem.
>> >
>> > I have not been following the full discussion on PEP 637, but I
>> > recall
>> > seeing another suggestion earlier for what this could be resolved
>> > into:
>> >
>> >     type(obj).__getitem__(obj, x=23)
>> >
>> > I.e., not passing a positional argument at all.
>> >
>> > The author of a class that supports keyword indexing could check this
>> > sort
>> > of case with a positional only argument with a default value, e.g.,
>> >
>> >     def __getitem__(self, key=MY_SENTINEL, /, **kwargs):
>> >
>> > where MY_SENTINEL could be any desired sentinel value, including
>> > either
>> > None or (). Is there a reason for rejecting this option? It seems
>> > like a
>> > nice explicit alternative to prespecifing the choice of sentinel
>> > value.
>> >
>> > I guess the concern might be that this would not suffice for
>> > __setitem__?
>> >
>> >
>> > >
>> > > You can see a detailed discussion in the PEP at L913
>>
>> <snip>
>>
>> > I guess the case this would disallow is distinguishing between
>> > obj[None,
>> > x=23] and obj[x=23]?
>> >
>> > Yes, this could be a little awkward potentially. The tuple would
>> > definitely
>> > be more natural for NumPy users, given the that first step of
>> > __getitem__/__setitem__ methods in the broader NumPy ecosystem is
>> > typically
>> > packing non-tuple keys into a tuple, e.g.,
>> >
>> >     def __getitem__(self, key):
>> >         if not isinstance(key, tuple):
>> >             key = (key,)
>> >         ...
>> >
>> > That said:
>> > - NumPy itself is unlikely to support keyword indexing anytime soon.
>> > - New packages could encourage using explicit aliases like
>> > "np.newaxis"
>> > instead of "None", which in general is a best practice already.
>> > - The combined use of keyword indexing *and* insertion of new axes at
>> > the
>> > same time strikes me as something that would be unusual in practice.
>> > From
>> > what I've seen, it is most useful to either use entirely unnamed or
>> > entirely named axes. In the later case, I might write something like
>> > obj[x=None] to indicate inserting a new dimension with the name "x".
>> >
>>
>> Just to briefly second these points and the general support thanks for
>> the hard work!  I do also wonder about the `key=custom_default`
>> solution, or whether there may be other option to address this.
>>
>> For NumPy, I do hope we can play with the idea of adding support if
>> this PEP lands. But agree that labeled axes in NumPy is unlikely to be
>> on the immediate horizon, and I am not sure how feasible it is.
>>
>> My main in the discussion on python-ideas was `arr[]` doing something
>> unexpected, but it was long decided that it will remain a SyntaxError.
>>
>> For the question at hand, it seems to me that mixing labeled and
>> unlabeled indexing would be an error for array-like objects.
>> In that case, the worst we get seems a quirk where `arr[None, x=4]` is
>> not an error, when it should be an error.
>> That does not really strike me as a blocker.
>>
>> I am not a fan of such quirks. But some trade-off seems unavoidable
>> considering the backward compatibility constraints and differences
>> between array-likes and typing use of `__getitem__`.
>>
>> - Sebastian
>>
>>
>> > I think we could definitely live with it either way. I would lean
>> > towards
>> > using an empty tuple, but I agree that it feels a little uglier than
>> > using
>> > None (though perhaps not surprising, given the already ugly special
>> > cases
>> > for tuples in the indexing protocol).
>> >
>> > Best,
>> > Stephan
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion at python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200925/00280e84/attachment-0001.html>


More information about the NumPy-Discussion mailing list