[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-05 Thread Brett Cannon
On Wed, Dec 4, 2019 at 3:12 PM Guido van Rossum wrote: > We could treat it as a kind of future statement. If there’s a top level > statement that defines the magic identitier we generate the special > bytecode. > True, that would help solve the performance issue. But I'm still -1 on the idea

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Guido van Rossum
We could treat it as a kind of future statement. If there’s a top level statement that defines the magic identitier we generate the special bytecode. On Wed, Dec 4, 2019 at 12:26 Brett Cannon wrote: > > > On Tue, Dec 3, 2019 at 5:58 PM Random832 wrote: > >> On Tue, Dec 3, 2019, at 13:43, Brett

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Brett Cannon
On Tue, Dec 3, 2019 at 5:58 PM Random832 wrote: > On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote: > > -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.

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Serhiy Storchaka
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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Random832
On Wed, Dec 4, 2019, at 11:51, Chris Angelico wrote: > Which of these are you expecting to be detected, and thus cause the > change in bytecode? More or less the same sort of operations where the use of the name super is detected within methods and causes the enclosing class to have a __class__

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Random832
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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Chris Angelico
On Thu, Dec 5, 2019 at 3:41 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.

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Ethan Furman
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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread 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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-04 Thread Serhiy Storchaka
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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-03 Thread Random832
On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote: > -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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-03 Thread Brett Cannon
On Tue, Dec 3, 2019 at 8:29 AM Random832 wrote: > What if there was a general mechanism to allow operators to be implemented > by user code that does not belong to the class? > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > within that module all calls to that

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-03 Thread Random832
On Tue, Dec 3, 2019, at 11:36, Ricky Teachey wrote: > > > What if there was a general mechanism to allow operators to be implemented > > by user code that does not belong to the class? > > > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > > within that module all

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

2019-12-03 Thread Ricky Teachey
> What if there was a general mechanism to allow operators to be implemented > by user code that does not belong to the class? > > If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, > within that module all calls to that operator are replaced with a two-step > process: > > *