On Wed, Aug 26, 2020 at 7:58 AM Chris Angelico <ros...@gmail.com> wrote:
> -1. We have already had way WAY too much debate about the alternative > ways to handle kwargs in subscripts, and quite frankly, I don't think > this is adding anything new to the discussion. Can we just stop > bikeshedding this already and let this matter settle down? You still > aren't showing any advantage over just allowing the current dunder to > receive kwargs. > > ChrisA > On Wed, Aug 26, 2020, 8:02 AM Steven D'Aprano <st...@pearwood.info> wrote: > Please don't hijack an existing PEP for an unrelated issue. > > PEP 472 is an existing PEP for "Support for indexing with keyword > arguments". > > https://www.python.org/dev/peps/pep-0472/ > > If you want to write a competing PEP, see PEP 1 for the steps you must > follow: > > https://www.python.org/dev/peps/pep-0001 I think Jonathan included the name of pep 472 in the subject line just because it's related to the previous conversations that have been going on, not to hijack the PEP for a different purpose. I understand that Steve has said he is very grumpy about all of this hijacking, derailing, bikeshedding, or whatever other metaphors are appropriate for the alternative ideas that are being proposed for future functionality that he cares about and wants to use. Perhaps this applies to Chris and others as well. But I have to say that I think this latest is a fantastic idea, and when Jonathan presented it to me it was very surprising that I had not seen it presented by anyone else yet. I think it solves a ton of problems, adds a huge amount of flexibility and functionality, and as such has the potential to be very powerful. There are at least three substantive objections I see to this: 1. It will slow down subscripting 2. It adds complexity 3. It actually doesn't add anything helpful/useful *Objection 1: Slowing Things Down* The INTENDED EFFECT of the changes to internals will be as Jonathan Fine described: every time a subscript operation occurs, this new dunder attribute gets investigated on the class, and if it is not present then the default key translation function is executed. If things were implemented in exactly that way, obviously it would slow everything down a lot. Every subscripting operation gets slowed down everywhere and that's probably not an option. However, for actual implementation, there's no reason to do that. Instead we could wrap the existing item dunder methods automatically at class creation time only when the new dunder attribute is present. If it is not present, nothing happens. In other words, what has been described as the "default key or index translation function" already exists. Let's not change that at all for classes that do not choose to use it. This would have the same effect as the proposal, but it would avoid any slowdown when a class has not provided the new attribute. Also note that this can coexist alongside Steve's and Chris's preferred solution, which is to just add kwarg passing to the item dunders. That change would constitute and adjustment to the "default key or index translation function", which is sort of like this (from Jonathan's first message): def internal_get_function(self, *argv, **kwargs): if kwargs: raise SyntaxError if len(argv) == 1: key = argv[0] else: key = argv type(self).__getitem__(self, key) *Objection 2: Adds complexity* This is hard to argue with. It certainly does add complexity. The question is whether the complexity is worth the added benefits. But in the interest of arguing that the additional complexity is not THAT onerous, I will point out that in order to add flexibility, complexity is nearly always necessitated. *Objection 3: Doesn't add anything useful/helpful* This objection seems obviously false. With the proposal, the language would support any function desired to turn the "stuff" inside a subscripting operation into the item dunder calls. For example: if this proposal were already in place and PEP 472 were to continue to be held up because of terrorists like me ;) *, one could have written this translation function and PEP-472-ify their classes already: def yay_kwargs(self, *args, **kwargs): return self.__getitem__(args, **kwargs) But another person, who doesn't like PEP 472, could do something else: def boo_kwargs(self, *args, **kwargs): if kwargs: raise SyntaxError("I prefer to live in the past.") return self.__getitem__(args) * I'm trying to be light, I'm really not offended by Steve's or Chris's comments, and I really am earnestly trying to offer something helpful here, not hold things up for people. I care about adding kwargs to the subscript operator, too. >
_______________________________________________ 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/C5LLV2GJKZW344WKKDMZP54CMGXJBM2T/ Code of Conduct: http://python.org/psf/codeofconduct/
