-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/14/2011 1:23 AM, Martin (gzlist) wrote:
On 07/04/2011, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 07/04/2011 20:18, Robert Collins wrote:
Testtools did something to address this problem, but I forget what it
was offhand.
Some
On 14/04/2011 00:23, Martin (gzlist) wrote:
On 07/04/2011, Michael Foordfuzzy...@voidspace.org.uk wrote:
On 07/04/2011 20:18, Robert Collins wrote:
Testtools did something to address this problem, but I forget what it
was offhand.
Some issues were worked around, but I don't remember any
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
I think you have the wrong issue #; that one has to do with string
exceptions.
On Wed, Apr 13, 2011 at 22:21, senthil.kumaran
python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/7563f10275a2
changeset: 69350:7563f10275a2
parent: 69344:1f767f834e67
parent:
Hi all,
it all started with issue10019.
The version we have in cpython of json is simplejson 2.0.9 highly
patched (either because it was converted to py3k, and because of the
normal flow of issues/bugfixes) while upstream have already released
2.1.13 .
Their 2 roads had diverged a lot, and since
On Thu, 14 Apr 2011 21:22:27 +0200
Sandro Tosi sandro.t...@gmail.com wrote:
But how am I going to do this? let's do a brain-dump:
IMHO, you should compute the diff between 2.0.9 and 2.1.3 and try to
apply it to the CPython source tree (you'll probably have to change the
file paths).
- what
- what are we going to do in the long run? how can we assure we'll be
having a healthy collaboration with upsteam? f.e. in case a bug is
reported (and later on fixed) in cpython? is there a policy for
projects present in cpython and also maintained elsewhere?
At the end: do you have some
On Apr 14, 2011, at 12:22 PM, Sandro Tosi wrote:
The version we have in cpython of json is simplejson 2.0.9 highly
patched (either because it was converted to py3k, and because of the
normal flow of issues/bugfixes) while upstream have already released
2.1.13 .
Their 2 roads had diverged
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
On Apr 10, 2011, at 2:44 PM, Antoine Pitrou wrote:
On Sun, 10 Apr 2011 21:58:40 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
Ultimately, it's up to Georg and Antoine to decide whether they want
to accept the load.
I don't want to maintain the Jython repo myself but if Georg or Philip
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
Ethan Furman et...@stoneleaf.us writes:
Here we have django's TestCase that does *not* want to call
unittest2.TestCase (assuming that's not a bug), but it gets called
anyway because the Mixin3 sibling has it as a base class. So does
this mean that TestCase and Mixin3 just don't play well
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
On 4/14/2011 2:53 PM, Brett Cannon wrote:
I think you have the wrong issue #; that one has to do with string
exceptions.
Fix closes Issue1147.
Right, wrong issue. Log should be corrected if it has not been.
+- Issue #11474: Fix the bug with url2pathname() handling of '/C|/'
on
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
On Thu, Apr 14, 2011 at 08:00:11PM -0400, Terry Reedy wrote:
On 4/14/2011 2:53 PM, Brett Cannon wrote:
I think you have the wrong issue #; that one has to do with string
exceptions.
Fix closes Issue1147.
Right, wrong issue. Log should be corrected if it has not been.
+- Issue
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
38 matches
Mail list logo
