On Wed, Dec 4, 2019, at 11:49, Ethan Furman wrote: > On 12/04/2019 08:39 AM, Random832 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. > > Are the low-level details, such as following the mro, in the bytecode? > If not, the bytecode would be the same either way.
No, but my proposal was for a new bytecode operation that is "check for hook and execute operator", with the explicit goal of avoiding both the performance penalty (especially on frequent operations like getattr and call) and the influence-at-a-distance concern. _______________________________________________ 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/YV3JIPNNJ5EORZDQP74GBPRBJ53Y7ZJ6/ Code of Conduct: http://python.org/psf/codeofconduct/
