On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini <stefano.bor...@gmail.com> wrote:
> Dear all, > > > > > > I would like to know your opinion on how to address a specific need of > > > the new PEP 637: > > > > > > https://github.com/python/peps/blob/master/pep-0637.txt > > > > > > Such PEP would make a syntax like the following valid > > > > > > obj[2, x=23] > > > obj[2, 4, x=23] > > > > > > Which would resolve to a call in the form > > > > > > type(obj).__getitem__(obj, 2, x=23) > > > type(obj).__getitem__(obj, (2, 4), x=23) > > > > > > and similar for set and del. > > > After discussion, we currently have one open point we are unsure how > > > to address, that is what to pass when no positional index is passed, > > > that is: > > > > > > obj[x=23] > > > > > > We are unsure if we should resolve this call with None or the empty > > > tuple in the positional index: > > > > > > type(obj).__getitem__(obj, None, x=23) > > > type(obj).__getitem__(obj, (), x=23) > > > > 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 > > > > > > > https://github.com/python/peps/blob/1fb19ac3a57c9793669ea9532fb840861d4d7566/pep-0637.txt#L913 > > > > > > One of the commenters on python-ideas reported that using None might > > > introduce an issue in numpy, as None is used to create new axes, hence > > > the proposal for rejection of None as a solution. > > > However, we are unsure how strongly this would affect numpy and > > > similar packages, as well as what developer will find more natural to > > > receive in that case. We would like to hear your opinion on the topic. > 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". 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
