On Fri, Aug 7, 2020 at 9:12 AM Ricky Teachey
On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano
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-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/BJOW5F... Code of Conduct: http://python.org/psf/codeofconduct/