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
On 17 April 2011 02:48, Steven D'Aprano st...@pearwood.info 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
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
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
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
On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner
ricardokirk...@gmail.com 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
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:
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
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
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
.
___
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-archive.com
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 is a
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,
On Fri, Apr 15, 2011 at 11:30 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 correctly.
Mark Shannon wrote:
class A: pass
class B(A): pass
class C(A,B):pass
Traceback (most recent call last):
File stdin, line 1, in module
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:
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
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
2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com:
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
On Thu, 14 Apr 2011 08:15:10 -0500
Benjamin Peterson benja...@python.org wrote:
2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com:
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
:-)
2011/4/14 Antoine Pitrou solip...@pitrou.net
On Thu, 14 Apr 2011 08:15:10 -0500
Benjamin Peterson benja...@python.org wrote:
2011/4/14 Ricardo Kirkner ricardokirk...@gmail.com:
Hi all,
I recently stumbled upon an issue with a class in the mro chain not
calling super,
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
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
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
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:
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
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
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
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
fuzzy...@voidspace.org.uk wrote:
On 14/04/2011 16:34, P.J. Eby wrote:
At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo
On Thu, Apr 14, 2011 at 16:18, Ronald Oussoren ronaldousso...@mac.com 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 :-)
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 an
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
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 *start* the
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
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 when you
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 example
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.
I'll
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
should
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
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
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):
...
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
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
On Fri, 15 Apr 2011 12:58:14 +1200, Greg Ewing greg.ew...@canterbury.ac.nz
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
44 matches
Mail list logo
