On Wed, Aug 26, 2020 at 9:48 AM Steven D'Aprano <st...@pearwood.info> wrote:
> Demonstration: > > > py> class Dynamic: > ... def __getitem__(self, arg): > ... print("original") > ... type(self).__getitem__ = lambda *args: > print("replaced") > ... > py> > py> x = Dynamic() > py> x[0] > original > py> x[0] > replaced > I see what you're saying there. So any solution involving `type` of `object` wrapping a child class method at class creation time should probably not be considered as a cpython implementation option because of the dynamic nature of classes. Understood. > > Sure, it might break some code because somebody, somewhere, has a > > __getitem__ method written like this: > > > > def __getitem__(self, a, b=None, c=None): ... > [...] > > But are you really saying there is a very important responsibility not to > > break that person's code? > > Yes. > Alright, you've made progress with me on this one. I'm still not totally convinced such code isn't asking to be broken, but you're right: just dismissing that as a nonissue isn't correct. It has to be weighed. > > > Maybe we wouldn't have designed subscripting this way back in Python 1 > > > if we know what we know now, but it works well enough, and we have > heard > > > from numpy developers like Stephan Hoyer that this is not a problem > that > > > needs fixing. Can we please stop trying to "fix" positional subscripts? > > > > > > > I'm not done trying, sorry. I think the incongruity is a problem. > > A problem for whom? > > A problem in what way? > > PEP 472 goes into detail about the sorts of things people find really > hard to do with subscripting because of the lack of keywords. Where is > the discussion by people about the things that are really hard to do > because of the comma handling in subscripts? > Well I will point to Greg Ewin's message from a while ago that I quoted at the start of this thread: On Tue, Aug 4, 2020, 2:57 AM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: On 4/08/20 1:16 pm, Steven D'Aprano wrote: > Why would we want to even consider a new approach to handling keyword > arguments which applies only to three dunder methods, `__getitem__`, > `__setitem__` and `__delitem__`, instead of handling keyword arguments > in the same way that every other method handles them? These methods are already kind of screwy in that they don't handle *positional* arguments in the usual way -- packing them into a tuple instead of passing them as individual arguments. I think this is messing up everyone's intuition on how indexing should be extended to incorporate keyword args, or even whether this should be done at all. -- Greg If we simply add kwarg passing to item dunders, the incongruity between the subscripting operator and regular function calls will really hinder people's ability to understand the two. I think most people in these conversations seem to now agree that this isn't a good enough reason to exercise the do nothing option, but I think it is a very good reason to explore other ways of doing it to alleviate that incongruity. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
_______________________________________________ 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/VR6TP5QBLUI7BD6WR4AFGLD7UNGFLX66/ Code of Conduct: http://python.org/psf/codeofconduct/