>
> Things to know about super:
> Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=236275
> Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=236278
> Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=237121
>
> The wonders of super:
> http://www.artima.com/weblogs/viewpost.j
On Sat, 4 Jun 2016 09:52 pm, Gregory Ewing wrote:
> Ian Kelly wrote:
>>
>> It can't belong to a subclass; the MRI guarantees that. But it's not
>> necessarily a superclass either.
>
> Er, yes, what I really meant to say was that it could
> be a class that got introduced into the MRO as a result
Steven D'Aprano wrote:
On Sat, 4 Jun 2016 11:06 am, Gregory Ewing wrote:
there is no need to use super.
Except then you are precluding others from integrating your classes into
their class hierarchies.
And if you *do* use super, you're precluding integrating them
into other hierarchies that
Ian Kelly wrote:
It can't belong to a subclass; the MRI guarantees that. But it's not
necessarily a superclass either.
Er, yes, what I really meant to say was that it could
be a class that got introduced into the MRO as a result
of someone else subclassing your class.
So when you make a super
On Jun 3, 2016 7:12 PM, "Gregory Ewing" wrote:
>
> 4. It must not matter what order the methods in a super
> chain are called. This is because you cannot predict
> which method a given super call will invoke. It could
> belong to a subclass of the class making the call.
It can't belong to a subcl
On Sat, 4 Jun 2016 11:06 am, Gregory Ewing wrote:
> Nagy László Zsolt wrote:
>> I do not use diamond shapes in my hierarchy, I guess that does not
>> affect me. I may be wrong.
>
> If there are no diamonds,
In Python 3, or Python 2 with new-style classes, there are ALWAYS diamonds
when you use
Ben Finney wrote:
With classes all inheriting ultimately from ‘object’ (as all Python 3
classes do, and as all current Python 2 classes should), mutliple
inheritance inevitably places your classes in a diamond inheritance
pattern.
That's usually harmless, though, because object provides
very li
Nagy László Zsolt wrote:
I do not use diamond shapes in my hierarchy, I guess that does not
affect me. I may be wrong.
If there are no diamonds, there is no need to use super.
Explicit inherited method calls, done correctly, will
work fine.
The only downside is that if your inheritance hierarc
Ian Kelly writes:
> Except that since we're discussing design for multiple inheritance,
> the positional argument "spam" is inappropriate. All arguments should
> be passed by keyword; the DolorSitAmet.__init__ method cannot be
> certain that LoremIpsum will be the next class in the MRO, and the
>
On Fri, Jun 3, 2016 at 2:16 PM, Ben Finney wrote:
> If you're writing a custom initialiser that handles two additional
> parameters, then those parameters should not be present when you call
> the super() method's initialiser::
>
> # You specified Python 3, which allows simpler syntax.
>
>
Nagy László Zsolt writes:
> Fortunately, I can change all of the classes, and extracting the
> common parameter into a common base class worked.
This is why Liskov's Substitution Principle is good: Thinking of it as a
law helps lead to better design.
In this case, the same parameter doing diffe
Nagy László Zsolt writes:
> So you are right: the custom __init__ in the BootstrapDesktop class is
> not really needed, and does not do anything useful in that particular
> class.
I disagree: setting initial attributes is a normal and useful case for
defining a custom initialiser.
> My original
On Fri, Jun 3, 2016 at 12:01 PM Nagy László Zsolt
wrote:
> > Is the problem that the attribute or parameter has the same name in
> both base classes, but has different meanings in each?
> If they had different meanings, a simple rename would solve the problem.
>
Sometimes finding a good name ain
Is the problem that the attribute or parameter has the same name in both
base classes, but has different meanings in each?
If they had different meanings, a simple rename would solve the problem.
They have the same meaning.
If you can't change the base classes, I've got some other solutions,
On Fri, Jun 3, 2016 at 10:41 AM Ian Kelly wrote:
> On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt
> wrote:
> > There is still something I don't get: how to create cooperative classes
> > when some base classes share some of the parameters?
>
> Why do they need to share the same parameter?
>
On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt wrote:
>
>>> That's overly strict. As Raymond shows, it is easy to deal with
>>> changing method signatures in *cooperative* classes.
>> I must watch that for sure.
>
> All right, I have read this:
>
> https://rhettinger.wordpress.com/2011/05/26/su
>> That's overly strict. As Raymond shows, it is easy to deal with
>> changing method signatures in *cooperative* classes.
> I must watch that for sure.
All right, I have read this:
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
There is still something I don't get: how to
>> But I have to initialize some default attributes.
> Then the statement “there is NOTHING else here” must be false. Either
> the custom ‘__init__’ does something useful, or it doesn't.
Well... the custom __init__ method with nothing else just a super() call
was expressed there to show the super
On Fri, 3 Jun 2016 07:18 am, Random832 wrote:
> On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
[...]
>> But since the constructor/initialiser methods are so closely linked, many
>> people are satisfied to speak loosely and refer to "the constructor" as
>> either, unless they specifically wi
> Raymond Hettinger gives an excellent presentation where he describes various
> problems with MI and gives solutions for them. I think this might be it:
>
> http://pyvideo.org/video/1094/the-art-of-subclassing-0
This is a much better version from one year later:
https://www.youtube.com/watch?v=m
Nagy László Zsolt writes:
> > [...]
> >> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
> >> def __init__(self, appserver, session):
> >> # there is NOTHING else here, it just connects bootstrap widget
> >> implementation with desktop methods
> >> super(BootstrapDeskto
>
> In Python 3, that will be automatic and you don't need to worry about it.
I'm using Python 3. I'm aware of old style and new style classes in
Python 2.
>
>
> [...]
>> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
>> def __init__(self, appserver, session):
>> # there is NOT
Random832 :
> But from a class-definition perspective, __init__ is the one and only
> thing that should be called a constructor.
Not arguing agaist that, but from the *user's* perspective, I see the
class itself is the constructor function:
class C: pass
c = C()
You could say that the clas
On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
> On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
>
> > On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> >> (Note that ‘__init__’ is not a constructor, because it operates on the
> >> *already constructed* instance,
On Thu, Jun 2, 2016 at 11:36 AM, Steven D'Aprano wrote:
> On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
>
>> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
>>> (Note that ‘__init__’ is not a constructor, because it operates on the
>>> *already constructed* instance, a
On Thu, 2 Jun 2016 06:22 pm, Lawrence D’Oliveiro wrote:
> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
>> (Note that ‘__init__’ is not a constructor, because it operates on the
>> *already constructed* instance, and does not return anything.
>
> Believe it or not, that *is*
On Thu, Jun 2, 2016 at 4:26 AM Lawrence D’Oliveiro
wrote:
> On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> > (Note that ‘__init__’ is not a constructor, because it operates on the
> > *already constructed* instance, and does not return anything.
>
> Believe it or not, that *
On Wednesday, June 1, 2016 at 8:02:14 AM UTC+12, Ben Finney wrote:
> (Note that ‘__init__’ is not a constructor, because it operates on the
> *already constructed* instance, and does not return anything.
Believe it or not, that *is* what “constructor” means in every OO language.
Technically it sh
On Wed, 1 Jun 2016 02:10 am, Nagy Lc3a1szlc3b3 Zsolt wrote:
> Today I come across this problem for the N+1st time. Here are some
> classes for the example:
A couple of comments... if you're using Python 2, then you may be having
trouble because none of the classes shown below inherit from object
Nagy László Zsolt writes:
> Today I come across this problem for the N+1st time. Here are some
> classes for the example:
Thank you for the example.
(Note that ‘__init__’ is not a constructor, because it operates on the
*already constructed* instance, and does not return anything. Python's
clas
30 matches
Mail list logo
