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()
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.
>
> >
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 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
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
Ethan Furman 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 together?
>
> Mayb
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 Apr 10, 2011, at 2:44 PM, Antoine Pitrou wrote:
> On Sun, 10 Apr 2011 21:58:40 +0200
> "Martin v. Löwis" 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
> acce
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: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 dive
> - 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 so
On Thu, 14 Apr 2011 21:22:27 +0200
Sandro Tosi 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 are we going to do i
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
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
wrote:
> http://hg.python.org/cpython/rev/7563f10275a2
> changeset: 69350:7563f10275a2
> parent: 69344:1f767f834e67
> parent: 69349:37d1b749eebb
> user:
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
On 14/04/2011 00:23, Martin (gzlist) wrote:
On 07/04/2011, Michael Foord 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 comprehensive solution.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/14/2011 1:23 AM, Martin (gzlist) wrote:
> On 07/04/2011, Michael Foord 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 worke
38 matches
Mail list logo