On Fri, Aug 7, 2020 at 6:29 PM Stephan Hoyer <shoyer@gmail.com> wrote:
On Fri, Aug 7, 2020 at 9:12 AM Ricky Teachey <ricky@teachey.org> wrote:
On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano <steve@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.

NumPy and pandas both care a lot about backwards compatibility, and don't like churn for the sake of churn.

Speaking as someone who has been contributing to these libraries for years, the present syntax for positional arguments in __getitem__ is not a big deal, and certainly isn't worth breaking backwards compatibility over.

In practice, this is worked around with a simple normalization step, e.g., something like:

def __getitem__(self, key):
    if not isinstance(key, tuple):
        key = (key,)
    # normal __getitem__ method

This precludes incompatible definitions for x[(1, 2)] and x[1, 2], but really, nobody this minor inconsistency is not a big deal. It is easy to write x[(1, 2), :] if you want to indicate a tuple for indexing along the first axis of an array.

From my perspective, the other reasonable way to add keyword arguments to indexing would be in a completely backwards compatible with **kwargs. 

I'm sorry, I did a poor job of editing this.

To fill in my missing word: From my perspective, the *only* reasonable way to add keyword arguments to indexing would be in a completely backwards compatible way with **kwargs. 

 

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-leave@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/