On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:
In this fashion have you considering having keyword only indices, that is to only allow either obj[1, 2] or obj[row=1, col=2] (if the class supports it), and disallow mixing positional and keyword indices, meaning obj[1, col=2] would be a SyntaxError.
That would severely reduce the usefulness of this feature for me, probably by 80 or 90%, and possibly make it useless for xarray and pandas. (I don't speak for the pandas or xarray devs, I'm happy to be corrected.) But for my own code, my primary use-case is to have a mixed positional index and keyword arguments. I would *much* rather give up keyword-only subscripting. Keyword-only subscripting would be a convenience and a useful feature, but it's mixed subscripting that I am really hungry for. Hmmm, that's a thought... maybe we should just prohibit keyword-only calls for now? People who want a "keyword only" call can provide their own "do nothing" sentinel as the index. For my own purposes, I could easily adapt the keyword-only cases to use None as an explicit sentinal: matrix[row=1] # Nice to have. matrix[None, row=1] # Good enough for my purposes. so for my own purposes, if keyword-only is too hard, I'd be happy to drop it out of the PEP and require an explicit index.
If we followed that path, then adding a new set of dunders may not be that problematic as the use case would be slightly different than the current semantics.
I don't see how "the use case is different" solves the problems with adding new dunders. Adding new dunders is problematic because: * they probably require new C level slots in objects, increasing their size; * and the added complexity and likelihood of confusion for developers. Do I write `__getitem__` or `__getindex__`? We had this back in Python 1 and 2 days with `__*item__` and `__*slice__` dunders and moved away from that, let's not revert back to that design if we can avoid it.
I also agree with Stefano that something like a[1, 2, unit="meters"] feels really odd,
Could be because of the misspelling of metres (unit of measurement) versus meters (things you read data from) *wink* Without knowing what the object `a` represents, or what the meaning of the subscript is, how can we possibly judge whether this is a reasonable use of a keyword subscript or not? Stefano wrote:
a[1, 2, unit="meters"]
makes me feel uncomfortable, although I might learn to accept it. In particular, the above case becomes kind of odd when you use it for setitem and delitem
a[1, 2, unit="meters"] = 3
what does this mean? convert 3 to meters and store the value in a?
You made the example up, so you should know what it means :-) I don't even know what `a[1, 2, unit="meters"]` means since we don't know what `a` is.
Then why isn't the unit close to 3, as in
a[1,2] = 3 * meters
and what about this one?
del a[1, 2, unit="meters"] # and this one?
In my own use-case, all three get/set/delete operations will support the same keywords, but just because we syntactically allow subscripts doesn't make it mandatory to use them identically useful for all three opperations in all cases. There is no need for the dunder to support a keyword that makes no sense for that dunder. For example, suppose we had a sequence-like mapping that supports this get operation: table[index, default="index out of range"] That doesn't mean that table has to support the same keyword when setting or deleting, it can use different keywords that make no sense when getting: table = Table([1, 2, 3, 4]) table[10, fill=-1] = 5 print(table) # => [1, 2, 3, 4, -1, -1, -1, -1, -1, -1, 5] del table[index, errors="ignore"] # Silence error if out of range. There's no requirement that the three get/set/delete operations have to use the same keywords, or any keywords at all, only that they *could* if required. *Allowing* symmetry between the three options is a must; *requiring* symmetry between them is not. -- Steve