On 26/08/20 10:03 am, Stefano Borini wrote:
But you have a point that whatever the implementation might be, it has to play nice with the current dict() behavior. Yet, if we were to add an enhanced dunder, nothing for the current dict would change.
Despite arguing against it earlier, I think I'm starting to shift towards being in favour of a new dunder. But only if it can be justified as existing in its own right alongside __getitem__, without any intention to deprecate or remove the latter. I think an argument can be made that the new dunder -- let's call it __getindex__ for now -- shouldn't be considered part of the mapping protocol. It's a new thing for classes that want to use the indexing notation in ways that don't fit the simple idea of mapping a key object to a value object. The only drawback I can think of right now is that it would make possible objects for which x[1, 2] and x[(1, 2)] were not equivalent. I don't think that's a serious problem. A class would always be able to arrange for its __getindex__ method to *make* them equivalent, and things like pandas would be encouraged to do so. For things like generic types, which use the index notation for something that isn't really indexing at all, it probably doesn't matter much. -- Greg _______________________________________________ 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/NIJAZKTHPBP6Q3462V3DBUWDTQ5NU7QU/ Code of Conduct: http://python.org/psf/codeofconduct/
