Personally I think Jonathan and I (and possibly a couple others) should form a separate subgroup and come up with a sensible and logical set of options in a proto-PEP. The topic has been discussed and we have plenty of ideas and opinions, and if we want to achieve something coherent we need to take it aside and dig deeper the various options until the whole proposal (or set of proposals) has been considered fully. There's little sense in going back and forth in the mailing list.
One thing I want to understand though, and it's clear that this is a potential dealbreaker: is there any chance that the steering council will actually accept such a feature once it's been fully fleshed out, considering that it's undeniable that there are use cases spanning through multiple fields? Because if not (whatever the reason might be) regardless of the possible options to implement it, it's clear that there's no point in exploring it further. On Wed, 26 Aug 2020 at 12:58, Chris Angelico <ros...@gmail.com> wrote: > > On Wed, Aug 26, 2020 at 9:44 PM Jonathan Fine <jfine2...@gmail.com> wrote: > > > > PROPOSAL > > I think it will help solve our problem, to give Z = type(z) a new dunder > > attribute that either is used as the internal_get_function, or is used > > inside a revised system-wide internal_get_function. > > > > That way, depending on the new dunder attribute on Z = type(z), sometimes > > >>> z[1, 2, a=3, b=4] > > >>> z.__getitem__(1, 2, a=3, b=4) > > are equivalent. And sometimes > > >>> z[1, 2, a=3, b=4] > > is equivalent to > > >>> key = K(1, 2, a=3, b=4) > > >>> z.__getitem__(key) > > all depending on the new dunder attribute on Z = type(z). > > > > -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 > _______________________________________________ > 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/UCYMGB4BKZK7HHUNEBA6OIMCGIZFRXMA/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini _______________________________________________ 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/4637KB2T45S7BTWZU4RNXXBZTWPV24ZD/ Code of Conduct: http://python.org/psf/codeofconduct/
