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 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/ZCTPCTJPS4X6D6BLGNMAEXPII2NMPNJN/
Code of Conduct: http://python.org/psf/codeofconduct/
