I’m not at all sure this Idea is possible, But even if so, there’s a real trick here. The [] operator is not a function call, it is a special operator that “takes” a single expression.
Thing[a, b] is not “getting” two objects, it is getting a single tuple, which is created by the comma. That is, expression: a,b Has the same value as: (a, b) Or tuple(a,b) Which means: t = tuple(a, b) thing[a, b] Is exactly the same as thing[a,b] And that equivalency needs to be maintained. In practice, two common use cases treat the resulting tuple essentially semantically differently: 1) Using tuples as dict keys i.e. a single value that happens to be a tuple is a common practice. 2) numpy uses the elements of a tuple as separate indices. I don’t think the interpreter would have any way to know which of these is intended. -CHB On Mon, Aug 24, 2020 at 10:12 AM Ricky Teachey <ri...@teachey.org> wrote: > Here is another way forward-- inspired by a conversation off-list with > Jonathan Fine. I am calling it "signature dependent semantics". > > > > > Right now, the semantic meaning of a __setitem__ function like this: > > # using ambiguous names for the parameters on purpose > def __setitem__ (self, a, b): ... > > ...is currently as follows: > *Note: below the === is not supposed to be code - I am using it as a way > to state the semantics on the RHS of the signature on the LHS.* > > SIGNATURE === SEMANTICS > (self, a, b) === (self, key_tuple, value) > > In the above, a on the left side, semantically, is the key tuple, and b in > the value on the RHS. > > So right now, line 1 below calls line 2: > > [1]: d[1, 2] = foo > [2]: d.__setitem__(key_tuple, value) > > And the call occurs this way: > > d.__setitem__((1,2), foo) > > So far, all of this is just a description of what currently happens. > > The > > > > signature dependent semantics > > > > proposal is NOT to change the semantic meaning of the above code in any > way. These semantics would be maintained. > > Signature dependent semantics, as the name suggests, would change the > semantic meaning of the __setitem__ signature in the case that more than > two parameters are given in the signature. > > In other words, if a signature is provided like this, with 3 or more > arguments: > > def: __setitem__(self, a, b, c): ... > > ...then in that case, the language would know there is a different > semantic meaning intended. > > Right now, the above signature would raise a TypeError: > > >>> class D: > ... def __setitem__(self, a, b, c): > ... ... > ... > >>> d=D() > >>> d[1,2] = object() > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: __setitem__() missing 1 required positional argument: 'c' > > However, using signature dependent semantics, the language would know to > call using semantics like this instead of raising a TypeError: > > d.__setitem__(foo, 1, 2) # value is first positional argument > > In other words, in the case that there are three or more arguments present > in the __getitem__ signature, the semantics of the signature CHANGES: > > SIGNATURE === CURRENT SEMANTICS: where key_tuple on the RHS contains > (a,b), and value on the RHS is just c > (self, a, b, c) === (self, key_tuple, value, CURRENTLY_UNUSED_PARAMETER) > > SIGNATURE === NEW SEMANTICS: a is value, b is positional argument 1, c is > positional argument 2 > (self, a, b, c) === (self, value, pos1, pos2) > > I'm no cpython expert, but I think signature dependent semantics for > __setitem__, as well as for __getitem__ and __delitem__, could be > implemented. > > And that change alone could be made INDEPENDENT of supporting kwd args, or > KeyObjects, or anything else. > > Furthermore, after > > > > signature dependent semantics were implemented (or perhaps at the same > time), semantics could easily be extended so that code like this: > > d[1, b=2] = foo > > ...on a an object with a __setitem__ signature like this: > > def __setitem__(self, value, a, b): ... > > ...gets called like this: > > d.__setitem__(foo, 1, b=2) > > BUT, it could also be implemented such that if that same item setting code > were made against a signature like this: > > def __setitem__(self, a, value): ... > > You would get a TypeError, because the semantic meaning of the signature > with just two positional arguments, key_tuple and value, does not support > kwd arguments. > > DOWNSIDE > > The biggest downside to this that I see is that it would be confusing to > the uninitiated, especially in the following case. > > If the signature dependent semantics proposal were to go forward, and one > wrote a signature with two arguments, the following semantic meaning could > be mistakenly expected: > > # mistaken perception of __setitem__ method semantics > SIGNATURE === MISTAKEN SEMANTICS > (self, a, b) === (self, value, atomic_key) > > The mistaken belief above stated outright is that the RHS atomic_key is > NOT a tuple, it is just b from the LHS. But this would not be correct. > > The actual semantics, in order to maintain backward compatibility, would > not change from what is currently true: > > # backward compatible semantics > SIGNATURE === CORRECT, CURRENT SEMANTICS > (self, a, b) === (self, key_tuple, value) > > The correct understanding illustrated above is that the RHS > > > > key_tuple > > > > is a tuple (containing b from the LHS) of the form (b,). > > That seems like potentially a big downside. But maybe not? I don't know. > > --- > 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/LBLS5OUXSICNKV6ZGDFTBGJNK2YWKNTD/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/WEFN7JB2SOUQ5WEFANBMRKQVWCZV777N/ Code of Conduct: http://python.org/psf/codeofconduct/
