Steve D'Aprano wrote:
But for the simple cases, using super() in Python 3 couldn't be easier.
The only "simple" use of super() is in the single inheritance
case. But that's also the case where it gains you the least
over an explicit inherited method call.
If you have multiple inheritance, and
On Sun, Apr 16, 2017 at 10:35 AM, Steve D'Aprano
wrote:
>
>> eaisier to just write the path in long-form.
>
> Easier and wrong.
>
> If you have multiple inheritance, and don't use super(), then your code is
> buggy, whether you have realised it or not.
>
> Manually calling your parent class is onl
On Sat, 15 Apr 2017 10:50 pm, Rick Johnson wrote:
> Even to this day, i avoid super because the
> semantics are confusing,
If super() is confusing, it is because *inheritance* is confusing, and that
goes triple for multiple inheritance. If it is not *easy* to use super() to
manage your class' in
On Thursday, April 13, 2017 at 2:01:41 AM UTC-5, Serhiy Storchaka wrote:
>
> __init__ is perhaps the most called dunder method. It is
> often called from the __init__ method of subclasses.
Yes, that would be one of the exceptions to the rule, but
not because the rule is unsound, but because Python
On Thu, Apr 13, 2017 at 8:24 AM, Chris Warrick wrote:
> On 13 April 2017 at 09:43, eryk sun wrote:
>> The functions in the operator module implement abstract behavior (e.g.
>> PyNumber_Add in CPython):
>>
>> >>> operator.__add__(C(), D())
>> 42
>
> Those functions also do not need undersc
On Thu, Apr 13, 2017 at 4:18 PM, Rustom Mody wrote:
> I believe it was ChrisA who gave a pithy summary of the situation:
> Dont CALL dunders
> But its fine to DEFINE them
As others have mentioned, you call dunders during the definitions of
dunders, mainly during subclassing. But from outside the
On 13 April 2017 at 09:43, eryk sun wrote:
> The functions in the operator module implement abstract behavior (e.g.
> PyNumber_Add in CPython):
>
> >>> operator.__add__(C(), D())
> 42
Those functions also do not need underscores — operator.add is a
prettier way to achieve the same result.
On Thu, Apr 13, 2017 at 5:29 AM, Steven D'Aprano wrote:
>
> my_number.__add__(another_number)
>
> The short answer is:
>
> NO! In general, you shouldn't do it.
For example:
class C:
def __add__(self, other):
return NotImplemented
class D:
def __radd__(self, o
On Thu, Apr 13, 2017 at 5:29 AM, Steven D'Aprano wrote:
> Should you call dunder methods (Double leading and trailing UNDERscores)
> manually? For example:
>
>
> my_number.__add__(another_number)
>
>
> The short answer is:
>
> NO! In general, you shouldn't do it.
>
>
> Guido recently commented:
>
On 13.04.17 08:29, Steven D'Aprano wrote:
Should you call dunder methods (Double leading and trailing UNDERscores)
manually? For example:
my_number.__add__(another_number)
The short answer is:
NO! In general, you shouldn't do it.
Guido recently commented:
I agree that one shouldn't ca
On Thursday, April 13, 2017 at 11:00:03 AM UTC+5:30, Steven D'Aprano wrote:
> Should you call dunder methods (Double leading and trailing UNDERscores)
> manually? For example:
>
>
> my_number.__add__(another_number)
>
>
> The short answer is:
>
> NO! In general, you shouldn't do it.
>
>
> G
Should you call dunder methods (Double leading and trailing UNDERscores)
manually? For example:
my_number.__add__(another_number)
The short answer is:
NO! In general, you shouldn't do it.
Guido recently commented:
I agree that one shouldn't call __init__ manually (and in fact Python
12 matches
Mail list logo
