On Sun, Sep 27, 2020 at 5:58 PM Brett Cannon wrote:
>
>
> On Sun, Sep 27, 2020 at 2:58 PM Guido van Rossum wrote:
>
>> Hm... IIRC the reason why we did this for `__r*__` is because the more
>> derived class might want to return an instance of that class, and we can't
>> assume that the less deri
On Sun, Sep 27, 2020 at 2:58 PM Guido van Rossum wrote:
> Hm... IIRC the reason why we did this for `__r*__` is because the more
> derived class might want to return an instance of that class, and we can't
> assume that the less derived class knows how to create an instance of the
> more derived
Hm... IIRC the reason why we did this for `__r*__` is because the more
derived class might want to return an instance of that class, and we can't
assume that the less derived class knows how to create an instance of the
more derived class (the `__init__` signatures might differ).
For comparisons t
When you do a binary arithmetic operation, one of the things that dictates
whether the left-hand side's __*__ method is called before the right-hand
side's __r*__ method is if the left-hand side's __r*__ differs (there's
also the fact __r*__ methods are not called if. the types are the same).
Presu
I like this, but IMHO adding a character at the end of the macro name
(the exclamation mark), lowers readability.
I'd prefer a character at the start of the macro, a character that is
not used as an unary operator.
On Sat, 26 Sep 2020 at 14:11, Mark Shannon wrote:
>
> Hi everyone,
>
> I've submit
