Here is an illustration of what I am talking about:

sigdepsem: Signature Dependent Semantics

---
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 <ricky@teachey.org> wrote:
On Mon, Aug 24, 2020 at 1:52 PM Christopher Barker <pythonchb@gmail.com> 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