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 <ri...@teachey.org> wrote: > On Mon, Aug 24, 2020 at 1:52 PM Christopher Barker <python...@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 > > >
_______________________________________________ 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/GORFDMAEXHIB3BFXMNIYBEGZPFWQXMMC/ Code of Conduct: http://python.org/psf/codeofconduct/
