On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/BJOW5FVCNKNBWKMGAOIR2NYH6HKG4ONK/
Code of Conduct: http://python.org/psf/codeofconduct/
