On Tue, Aug 25, 2020 at 10:51:42PM -0400, Ricky Teachey wrote: > > The only way it could tell that would be to inspect *at runtime* the > > `__setitem__` method. And it would have to do this on every subscript > > call. Introspection is likely to be slow, possibly very slow. This would > > make subscripting slow. > > > > Well it would not have to inspect the signature on every subscript call,
Python is a very dynamic language and objects can change their own methods and even their class at any time, so, yes, it will have to inspect the signature on every call. Otherwise you are changing the language execution model. 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 [...] > People have actually been asking for ways to make subscripting operator act > more like a function call, so that's not true. Yes, people have asked for keyword arguments. This proposal doesn't get us any closer to the feature wanted. > And it could be useful. It doesn't give subscripting any additional functionality that doesn't already exist. It's a purely cosmetic change. > And > it does help address the problem of incongruity (though not perfectly) > between the way a function call handles args and kwargs, and the way the > subscript operator does it. And it is totally backwards compatible except > for the case [...] So not actually totally backwards compatible. Please stop calling things "totally backwards compatible" if they aren't totally backwards compatible. If you change the behaviour of existing legal code, it's not backwards compatible. > > 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? [...] > Remember: the signature dependent semantics proposal is to maintain > backwards compatibility, 100%, for any code that has been following the > very clear intent of the item dunder methods. The Python language doesn't follow the rule "Do what we intend you to do", it follows the rule "this is how the language works, do whatever the language allows". PEP 5 doesn't mention the word "intent" and doesn't say "its okay to break people's code if they are using Python in ways we don't like". You don't get to say that breaking legal code that works today is okay because it doesn't follow "the intent". It's still a breaking change and you have to convince the Steering Council that breaking other people's code for the sake of fixing an incongruity is worthwhile. Imagine it was code *you* relied on that broke, and you no longer had the source code for it, it was a library compiled away in a .pyc file and the company that distributed it has gone broke and the source code lost, and replacing that library is going to cost your business a year of time and a hundred thousand dollars in development costs. But that's okay, because an incongruity that makes no difference to anyone's code has been fixed. Now maybe you can convince the Steering Council that this is a clear win for the broader community. We do break backwards compatibility, sometimes, if the risks are small enough and the benefits large enough. But be honest about what you are doing. > 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. -- 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/B3ZY3BS6DHB23HNVERKXYVGXB2TSM56P/ Code of Conduct: http://python.org/psf/codeofconduct/