On Thu, Dec 5, 2019 at 3:41 AM Random832 random832@fastmail.com wrote:
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.
(There may be some confusion because of the 'if the hook is undefined' clause in the proposal: I intended that to apply if the hook is deleted or conditionally assigned - if it's never assigned at all, the code won't look for it when the operator is used.)
Which of these are you expecting to be detected, and thus cause the change in bytecode?
__operatorhook_or__ = lambda obj1, obj2: ...
def init(): global __operatorhook_or__ def __operatorhook_or__(obj1, obj2): ... init()
globals()["__operatorhook_or__"] = lambda obj1, obj2: ...
exec("def __operatorhook_or__(obj1, obj2): ...")
from othermodule import __operatorhook_or__
from othermodule import *
ChrisA