On Wed, Jun 23, 2021 at 6:41 AM Soni L. email@example.com wrote:
On 2021-06-22 5:23 p.m., Chris Angelico wrote:
On Wed, Jun 23, 2021 at 6:13 AM Soni L. firstname.lastname@example.org wrote:
Think about it like this, extension methods give you the ability to make imported functions that look like this:
look like this instead:
That's all there is to them. They're just a lie to change how you read/write the code. Some languages have an whole operator that has a similar function, where something like bar->foo(baz) is sugar for foo(bar, baz). The OP doesn't specify any particular mechanism for extension methods, so e.g. making the dot operator be implemented by a local function in the module, which delegates to the current attribute lookup mechanism by default, would be perfectly acceptable. It's like deprecating the existing dot operator and introducing a completely different one that has nothing to do with attribute lookup!
uh... I'm lost. Are you saying that that's a good thing? You *want* to replace the existing dot operator with one that has nothing to do with attribute lookup?? I don't get it.
Sure! As long as the new one can call getattr!
Let's say the new dot operator looks like this:
# file1.py def __dot__(left, right): print(left) print(right) ... foo =  foo.bar
Now, this would actually print the list  and the string "bar".
Then you can just use getattr to get attribute lookup behaviour out of it!
def __dot__(left, right): return getattr(left, right) foo =  foo.bar
It would have local scope, similar to uh... locals. Y'know how locals are just sugar for locals()['foo'] and stuff? Yeah.
Not really, no, they're not. :) The dictionary returned by locals() isn't actually an implementation detail of local name lookups.
Have you put any thought into how you would deal with the problem of recursive __dot__ calls?