On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano <st...@pearwood.info> wrote:
> On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote: > > > This proposal doesn't say anything about reversing the decision made all > > those years ago to bundle all positional arguments in a subscript into a > > single positional parameter. What's done is done, that's not going to > > change. > > Sorry, I was referring to the proposal that inspired this thread, to add > keyword arguments to subscripting. There's an actual concrete use-case > for adding this, specifically for typing annotations, and I cannot help > but feel that this thread is derailing the conversation to something > that has not been requested by anyone actually affected by it. > Well I wonder if they haven't asked because it would be such a huge change, and it seems unlikely to happen. But I surely don't know enough about the implementation details of these libraries to be able to say for certain one way or the other. I may have allowed my frustration to run ahead of me, sorry. > > There is a tonne of code that relies on subscripting positional > arguments to be bundled into a single parameter. Even if we agreed that > this was suboptimal, and I don't because I don't know the rationale for > doing it in the first place, I would be very surprised if the Steering > Council gave the go-ahead to a major disruption and complication to the > language just for the sake of making subscript dunders like other > functions. > Things would be different if, say, numpy or pandas or other heavy users > of subscripting said "we want the short term churn and pain for long > term benefit". > > But unless that happens, I feel this is just a case of piggy-backing a > large, disruptive change of minimal benefit onto a a small, focused > change, which tends to ruin the chances of the small change. So please > excuse my frustration, I will try to be less grumpy about it. > I understand the grumpiness given your explanation. I'm really not wanting to derail that kwd args proposal-- I really like it, whatever the semantics of it turn out to be. I was actually trying to help the kwd arg case here. As illustrated by the quote I included from Greg Ewing, there seems to be not even close to a consensus over what the semantic meaning of this should be: m[1, 2, a=3, b=2] Which could be made to mean one of the following things, or another thing I haven't considered: 1. m.__get__((1, 2), a=3, b=4) # handling of positional arguments unchanged from current behavior 2. m.__get__(1, 2, a=3, b=4) # change positional argument handling from current behavior 3. m.__get__((1, 2), {'a': 3, 'b': 4}) # handling of positional arguments unchanged from current behavior 4. m.__get__(KeyObject( (1, 2), {'a': 3, 'b': 4} )) # change positional argument handling from current behavior only in the case that kwd args are provided As Greg said: 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. To illustrate the comments of "kind of screwy" and "the usual way", using semantic meaning # 1 above, then these are totally equivalent * : m[1, 2, a=3, b=4] m[(1, 2), a=3, b=4] ...even though these are totally different: f(1, 2, a=3, b=4) f((1, 2), a=3, b=4) So my intention here isn't to derail, but to help the kwd argument proposal along by solving this screwiness problem. It is to suggest that maybe a way forward-- to make the intuition of the semantics of kwd args to [ ] much more obvious-- would be to change the signature so that this incongruity between what happens with "normal" method calls and the "call" for item-get/set/del can be smoothed out. If that incongruity were to be fixed, it seems to me it would become *obvious* that the semantic meaning of ` m[1, 2, a=3, b=2]` should definitely be: m.__get__(1, 2, a=3, b=4) But if all of this is not helping but hindering. I am happy to withdraw the idea. * Citing my source: I borrowed these examples from Jonathan Fine's message in the other thread --- 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/BJOW5FVCNKNBWKMGAOIR2NYH6HKG4ONK/ Code of Conduct: http://python.org/psf/codeofconduct/