Ricardo Kirkner wrote:
I'll give you the example I came upon:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase class in
Mark Janssen wrote:
I have to say it is quite strange to
me that there is no distinction made between IS-A relationship and
HAS-A relationships with regard to the issue of Inheritence.
I'm not sure what you mean by that. Inheritance is (or
should be) used only for is-a relationships. Misusing i
16.04.2011 03:38, Greg Ewing пишет:
Michael Foord wrote:
consider the "recently" introduced problem caused by object.__init__
> not taking arguments. This makes it impossible to use super correctly
> in various circumstances.
>
> ...
>
It is impossible to inherit from both C and A and have all
On 17 April 2011 02:48, Steven D'Aprano wrote:
> Michael Foord wrote:
>
>> On 15/04/2011 02:23, Steven D'Aprano wrote:
>>
> [...]
>
> If we treat django's failure to use super as a bug, you want the Python
>>> language to work-around that bug so that:
>>>
>>
>> What you say (that this particular
Argh! Sorry list. I meant to discard the post that was just sent.
Please accept my humblest apologies...
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner
wrote:
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all classes
Michael Foord wrote:
On 15/04/2011 02:23, Steven D'Aprano wrote:
[...]
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is true, however consi
Michael Foord wrote:
But you have to be aware that
because of the semantics of super, not calling up to your parents
basically prevents those methods being used in the presence of multiple
inheritance.
No, it prevents them being used in the presence of super().
Multiple inheritance is still p
Mark Shannon wrote:
class A: pass
class B(A): pass
class C(A,B):pass
Traceback (most recent call last):
File "", line 1, in
TypeError: Cannot create a consistent method resolution
order (MRO) for bases B, A
All right, but this is okay:
class C(B, A): pass
> Michael Foord wrote:
>
For a
Michael Foord wrote:
consider the "recently" introduced problem caused by object.__init__
> not taking arguments. This makes it impossible to use super correctly
> in various circumstances.
>
> ...
>
It is impossible to inherit from both C and A and have all parent
__init__ methods called corr
On Fri, Apr 15, 2011 at 11:30 PM, Michael Foord
wrote:
> On 15/04/2011 02:02, Greg Ewing wrote:
>> There isn't necessarily a clear distinction between parents
>> and siblings.
>>
>> class A:
>> ...
>>
>> class B(A):
>> ...
>>
>> class C(A, B):
>> ...
>>
>> In C, is A a parent of B or a sibling
On 15/04/2011 16:18, Carl Meyer wrote:
On 04/15/2011 08:53 AM, Michael Foord wrote:
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is true,
J
On 04/15/2011 08:53 AM, Michael Foord wrote:
>> If we treat django's failure to use super as a bug, you want the
>> Python language to work-around that bug so that:
>
> What you say (that this particular circumstance could be treated as a
> bug in django) is true,
Just as a side note: if there
Michael Foord wrote:
On 15/04/2011 02:02, Greg Ewing wrote:
Michael Foord wrote:
What I was suggesting is that a method not calling super shouldn't
stop a *sibling* method being called, but could still prevent the
*parent* method being called.
There isn't necessarily a clear distinction betwe
On 15/04/2011 02:23, Steven D'Aprano wrote:
Ricardo Kirkner wrote:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase cl
On 15/04/2011 02:02, Greg Ewing wrote:
Michael Foord wrote:
What I was suggesting is that a method not calling super shouldn't
stop a *sibling* method being called, but could still prevent the
*parent* method being called.
There isn't necessarily a clear distinction between parents
and siblin
R. David Murray wrote:
Why not? It seems more useful than using it for chaining,
especially given the compiler hack in Python3.
Because it's prone to doing the wrong thing if the class
using it is ever involved in multiple inheritance. If
you're expecting the call to go to a particular class,
On Fri, 15 Apr 2011 12:58:14 +1200, Greg Ewing
wrote:
> P.J. Eby wrote:
>
> > It's perfectly sensible and useful for there to be classes that
> > intentionally fail to call super(), and yet have a subclass that wants
> > to use super().
>
> One such case is where someone is using super() in a
Raymond Hettinger wrote:
If an external non-cooperative class needs to be used, then
it should be wrapped in a class that makes an explicit
__init__ call to the external class and then calls super().__init__()
to continue the forwarding.
I don't think it's as simple as that. Isn't that super()
Ricardo Kirkner wrote:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase class inherits from unittest2.TestCase, which w
Michael Foord wrote:
What I was suggesting is that a method not calling
super shouldn't stop a *sibling* method being called, but could still
prevent the *parent* method being called.
There isn't necessarily a clear distinction between parents
and siblings.
class A:
...
class B(A):
...
P.J. Eby wrote:
It's perfectly sensible and useful for there to be classes that
intentionally fail to call super(), and yet have a subclass that wants
to use super().
One such case is where someone is using super() in a
single-inheritance environment as a way of not having to
write the base c
Ricardo Kirkner wrote:
My question is,
shouldn't/wouldn't it be better,
if python took ownership of that part, and ensured all classes get
called, even if some class misbehaved?
I don't think so. If a class isn't designed to be part of
a super chain, there are likely to be other issues that
can
On Apr 14, 2011, at 3:32 PM, Ricardo Kirkner wrote:
>>
>> What would the semantics be of a super that intentially calls all siblings?
>> In particular what is the return value of such a call? The implementation
>> can't know how to combine the implementations in the inheritance chain and
>> s
Ricardo Kirkner wrote:
What would the semantics be of a super that intentially calls all
>> siblings? In particular what is the return value of such a call?
>> The implementation can't know how to combine the implementations
>> in the inheritance chain and should refuse the tempation to guess.
>
> What would the semantics be of a super that intentially calls all siblings?
> In particular what is the return value of such a call? The implementation
> can't know how to combine the implementations in the inheritance chain and
> should refuse the tempation to guess.
I'll give you the exam
On Thu, 2011-04-14 at 17:10 +0100, Michael Foord wrote:
> On 14/04/2011 17:02, Raymond Hettinger wrote:
> > On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
> >
> >> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
> >>> Ricardo isn't suggesting that Python should always call super for you,
> >>> but
On Apr 14, 2011, at 12:59 PM, Ronald Oussoren wrote:
> What would the semantics be of a super that (...)
I think it's long past time that this move to python-ideas, if you don't mind.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On 14 Apr, 2011, at 18:10, Michael Foord wrote:
> On 14/04/2011 17:02, Raymond Hettinger wrote:
>> On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
>>
>>> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo isn't suggesting that Python should always call super for you, but
when you
On 14/04/2011 17:02, Raymond Hettinger wrote:
On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo isn't suggesting that Python should always call super for you, but when
you *start* the chain by calling super then Python could ensure that all
On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
>> Ricardo isn't suggesting that Python should always call super for you, but
>> when you *start* the chain by calling super then Python could ensure that
>> all the methods are called for you. If a
On Thu, Apr 14, 2011 at 16:18, Ronald Oussoren wrote:
> It would be odd to not call super in __init__, but for other methods not
> calling the superclass implementation is fairly common.
Yes it is odd, that for example list.__init__ doesn't call super :-)
(http://bugs.python.org/issue8733)
Dani
Exactly what Michael said. Stopping the chain going upwards is one
thing. Stopping it going sideways is another.
On Thu, Apr 14, 2011 at 12:37 PM, Michael Foord
wrote:
> On 14/04/2011 16:34, P.J. Eby wrote:
>>
>> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
>>>
>>> Ricardo isn't suggesting t
On 14/04/2011 16:34, P.J. Eby wrote:
At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo isn't suggesting that Python should always call super for
you, but when you *start* the chain by calling super then Python
could ensure that all the methods are called for you. If an
individual metho
At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo isn't suggesting that Python should always call super for
you, but when you *start* the chain by calling super then Python
could ensure that all the methods are called for you. If an
individual method doesn't call super then a theoretica
On 14/04/2011 16:02, Laura Creighton wrote:
I think that if you add this, people will start relying on it.
And the specific problem with that would be?
Michael
Laura
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May
I think that if you add this, people will start relying on it.
Laura
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-arch
On 14/04/2011 15:18, Ronald Oussoren wrote:
On 14 Apr, 2011, at 15:09, Ricardo Kirkner wrote:
Hi all,
I recently stumbled upon an issue with a class in the mro chain not
calling super, therefore breaking the chain (ie, further base classes
along the chain didn't get called).
I understand it is
On 14 Apr, 2011, at 15:09, Ricardo Kirkner wrote:
> Hi all,
>
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all
Ricardo Kirkner wrote:
Hi all,
I recently stumbled upon an issue with a class in the mro chain not
calling super, therefore breaking the chain (ie, further base classes
along the chain didn't get called).
I understand it is currently a requirement that all classes that are
part of the mro chain
:-)
2011/4/14 Antoine Pitrou
> On Thu, 14 Apr 2011 08:15:10 -0500
> Benjamin Peterson wrote:
> > 2011/4/14 Ricardo Kirkner :
> > > Hi all,
> > >
> > > I recently stumbled upon an issue with a class in the mro chain not
> > > calling super, therefore breaking the chain (ie, further base classes
On Thu, 14 Apr 2011 08:15:10 -0500
Benjamin Peterson wrote:
> 2011/4/14 Ricardo Kirkner :
> > Hi all,
> >
> > I recently stumbled upon an issue with a class in the mro chain not
> > calling super, therefore breaking the chain (ie, further base classes
> > along the chain didn't get called).
> > I
2011/4/14 Ricardo Kirkner :
> Hi all,
>
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all classes that are
> part o
Hi all,
I recently stumbled upon an issue with a class in the mro chain not
calling super, therefore breaking the chain (ie, further base classes
along the chain didn't get called).
I understand it is currently a requirement that all classes that are
part of the mro chain behave and always call su
44 matches
Mail list logo
