On Wed, Aug 26, 2020, 18:04 Stefano Borini <stefano.bor...@gmail.com> wrote:
> On Wed, 26 Aug 2020 at 17:50, David Mertz <me...@gnosis.cx> wrote: > > > > In my mind, *anything* other than the straightforward and obvious > signature `__getitem__(self, index, **kws)` is a pointless distraction. > > It isn't. > and the reason why it isn't is that it makes it much harder for the > implementing code to decide how to proceed, for the following reasons: > 1. you will have to check if the keywords you receive are actually in > the acceptable set > 2. you will have to disambiguate an argument that is supposed to be > passed _either_ as position or with keyword. Always remember this use > case: a matrix of acquired data, where the row is the time and the > column is the detector. > I've seen countless times situations where people were creating the > matrix with the wrong orientation, putting the detector along the rows > and the time along the column. so you want this > > acquired_data[time, detector] > > to be allowed to be written as > > acquired_data[time=time, detector=detector] > > so that it's unambiguous and you can even mess up the order, but the > right thing will be done, without having to remember which one is > along the row and which one is along the column. > > If you use the interface you propose, now the __getitem__ code has to > resolve the ambiguity of intermediate cases, and do the appropriate > mapping from keyword to positional. Which is annoying and you are > basically doing manually what you would get for free in any standard > function call. > > Can you do it with that implementation you propose? sure, why not, > it's code after all. Is it easy and/or practical? not so sure. Is > there a better way? I don't know. That's what we are here for. > > To me, most of the discussion is being derailed in deciding how this > should look like on the __getitem__ end and how to implement it, but > we haven't even decided what it should look like from the outside > (although it's probably in the massive number of emails I am trying to > aggregate in the new PEP). > Again, implicit on your argument here is the assumption that all keyword indices necessarily map into positional indices. This may be the case with the use-case you had in mind. But for other use-cases brought up so far that assumption is false. Your approach would make those use cases extremely difficult if not impossible. >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WZZRIT7XOBTIN4PHVN24MNTESX73Q4UW/ Code of Conduct: http://python.org/psf/codeofconduct/
