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.) _______________________________________________ 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/QYSBJBP3VGYPVYRGM4FG23QGZKRDNZGI/ Code of Conduct: http://python.org/psf/codeofconduct/
