On Sun, Sep 27, 2020 at 12:43 AM Steven D'Aprano <st...@pearwood.info> wrote:
> 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. > Hi Steven, could you share some examples of what you have in mind. Having a more concrete example of an API that would benefit from mixed-subscripting would allow us to better understand its usefulness. I'm uneasy with the abuse-of-notation potential of this proposed feature, especially around the use of **kwd and mixed subscripting. That being said, I do understand why it may be appealing to others, as that could open the door for a more expressive language and maybe even better suited for some DSLs. > > 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 > _______________________________________________ > 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/OEBA3N5UXSTJL3QIQMQIHQ5DOBTAYETL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Sebastian Kreft
_______________________________________________ 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/5ANOFZWU7ZHZJSZESYUGYLFBJLJCUIIK/ Code of Conduct: http://python.org/psf/codeofconduct/
