On Fri, Aug 7, 2020 at 6:29 PM Stephan Hoyer <sho...@gmail.com> wrote:
> On Fri, Aug 7, 2020 at 9:12 AM Ricky Teachey <ri...@teachey.org> wrote:
>
>> 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.
>>
>
> 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-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/
>>
>
_______________________________________________
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/LPVT6TZY3GJQ32B6EAWF2VVIFRZRQADR/
Code of Conduct: http://python.org/psf/codeofconduct/
