04.12.19 18:39, Random832 пише:
On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote:
03.12.19 20:43, Brett Cannon пише:
-1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this wouldn't be fun either. To me this is monkeypatching without an explicit need for it, i.e. if you really want different semantics in your module then define a function and use that instead of influence-at-a-distance overriding of syntax.
This will also add a significant performance penalty to any code (even if you do not use any hooks). -1 from me too.
My proposal was that any module that never uses any hooks compiles to the exact same bytecode, and executes exactly the same way, as it does now. Only modules where the name of the hook is defined get a different operation that looks for the hook. I specifically wrote it that way to *avoid* any performance penalty for modules that do not use any hooks, or for operators other than the one a hook is defined for.
It is not possible. First, the code using operators can be above the code for the hook. Second, the code is generated at the compile time, but the hook is defined at the run time (when all module variables are defined). Third, the hook can be defined not only by the "def" statement in the module body. So the hook should be checked dynamically and it is much more expensive than using a field of the C structure.