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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
