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

[Aaron Meurer]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200924/9b47374a/attachment.html>