Here is an illustration of what I am talking about:
sigdepsem: Signature Dependent Semantics
https://github.com/Ricyteach/sigdepsem
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Mon, Aug 24, 2020 at 2:10 PM Ricky Teachey
On Mon, Aug 24, 2020 at 1:52 PM Christopher Barker
wrote: 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
The interpreter wouldn't. I'm talking about adding this knowledge of signature dependent semantics to `type`.
To implement this, under the hood `type` would detect the signatures with different semantics, and choose to wrap the functions with those signatures in a closure based on the intended semantic meaning. Then everything proceeds as it does today.
All of this is possible today, of course, using a metaclass, or using a regular class and the __init_subclass__ method, or using decorators. But my suggestion is to roll it into type.
--- Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler