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 <sebast...@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.bor...@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@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
