On 2021-06-22 5:34 p.m., Brendan Barnwell wrote: > On 2021-06-22 13:09, Soni L. wrote: >> Think about it like this, extension methods give you the ability to make >> imported functions that look like this: >> >> foo(bar, baz) >> >> look like this instead: >> >> bar.foo(baz) >> >> 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! > > Okay, if that's the case, then I just think it's a bad idea. :-) > > We already have a definition for what bar.foo does, and it's > totally under the control of the bar object (via the > __getattr__/__getattribute__ mechanism). The idea that other things > would be able to hook in there does not appeal to me at all. > > I don't really understand why you would want such a thing, to be > honest. I feel it would make code way more difficult to reason about, > as it would break locality constraints every which way. Now every > time you see`bar.foo` you would have to think about all kinds of other > modules that may be hooking in and adding their own complications. > What's the point? > > Mostly the whole benefit of the dot notation is that it specifies > a locally constrained relationship between the object and the > attribute: you know that bar.foo does what bar decides, and no one > else gets any say (unless bar asks for their opinion, e.g. by > consulting global variables or whatever). If we want to write > foo(bar, baz). . . well, we can just do that! What you're describing > would just make existing attribute usages harder to understand while > only "adding" something we can already do quite straightforwardly. > > Imagine a similar proposal for other syntax. Suppose that in any > module I could define a function called operator_add and then other > modules could "import" this "extension" so that every use of the + > operator would somehow hook into this operator_add function. So now > every time you do 2 + 2 you might be invoking some extension behavior. > In my view that is unambiguously a road to madness, and as far as I > can tell the extension mechanism you're proposing is equally ill-advised. >
Imagine if Python didn't have an + operator, but instead an + *infix function*. Thus, every module would automatically include the global def infix +(left, right): ... And indeed, you could say we already have this. Except currently you can't define your own local infix +. But what if you *could*? What if you could just, # file1.py def infix +(left, right): return left << right x = 4 + 4 # file2.py def infix +(left, right): return left ** right x = 4 + 4 # file3.py import file1 import file2 print(file1.x) # 64 print(file2.x) # 256 print(4 + 4) # 8 How does this break locality? Same idea with the dot operator, really. (Some languages don't have operators, but only functions. They let you do just this.) _______________________________________________ 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/QBQCSJELOHSPOG24X2LMSYBSKCGQRVYP/ Code of Conduct: http://python.org/psf/codeofconduct/
