On 05/07/2023 01:27, Chris Angelico via Python-list wrote:
>> So I'm curious about how big this "big problem with MI" is in
>
> Who said it's a big problem with MI?
I think it's a very common perception, particularly with
newer programmers who have never used it in anger. Any
time anyone discus
On Wed, 5 Jul 2023 at 10:31, Greg Ewing via Python-list
wrote:
>
> On 5/07/23 10:33 am, Alan Gauld wrote:
> > (*) C++ is the odd one out because it doesn't have GC, but then
> > neither does it have an Object superclass so very often MI in C++
> > does not involve creating diamonds! And especially
On 5/07/23 10:33 am, Alan Gauld wrote:
(*) C++ is the odd one out because it doesn't have GC, but then
neither does it have an Object superclass so very often MI in C++
does not involve creating diamonds! And especially if the MI
style is mixin based.
Even if all your mixins have empty construc
On Wed, 5 Jul 2023 at 08:35, Alan Gauld via Python-list
wrote:
>
> On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> > On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
> >> The legacy code I'm working with uses a classic diamond inheritance.
>
On 03/07/2023 19:39, Chris Angelico via Python-list wrote:
> On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
>> The legacy code I'm working with uses a classic diamond inheritance.
> What happens when Top is initialized twice? This seems like a problem
> waiting to
On Tue, 4 Jul 2023 at 22:06, Peter Slížik via Python-list
wrote:
>
> >
> > Also, you might find that because of the MRO, super() in your Bottom
> > class would actually give you what you want.
> >
>
> I knew this, but I wanted to save myself some refactoring, as the legacy
> code used different si
>
> Also, you might find that because of the MRO, super() in your Bottom
> class would actually give you what you want.
>
I knew this, but I wanted to save myself some refactoring, as the legacy
code used different signatures for Left.__init__() and Right.__init__().
I realized the formatting of
On 7/3/23 12:13, Mats Wichmann via Python-list wrote:
To natter on a bit, and possibly muddy the waters even further...
Now, as I see it, from the super()'s point of view, there are two
inheritance chains, one starting at Left and the other at Right. But
*Right.__init__()* is called twic
On Tue, 4 Jul 2023 at 03:39, Peter Slížik via Python-list
wrote:
>
> Hello.
>
> The legacy code I'm working with uses a classic diamond inheritance. Let me
> call the classes *Top*, *Left*, *Right*, and *Bottom*.
> This is a trivial textbook example. The classes were wri
On 7/3/23 12:01, Richard Damon via Python-list wrote:
On 7/3/23 1:38 PM, Peter Slížik via Python-list wrote:
Hello.
The legacy code I'm working with uses a classic diamond inheritance.
Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example
On 7/3/23 1:38 PM, Peter Slížik via Python-list wrote:
Hello.
The legacy code I'm working with uses a classic diamond inheritance. Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classes were written in the
pre-super() era, so all of
Hello.
The legacy code I'm working with uses a classic diamond inheritance. Let me
call the classes *Top*, *Left*, *Right*, and *Bottom*.
This is a trivial textbook example. The classes were written in the
pre-super() era, so all of them initialized their parents and Bottom
initialized both
On 10/02/2022 09:20, Igor Basko wrote:
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example class B and class C inherit from A
On 2021-05-20, Terry Reedy wrote:
> On 5/20/2021 2:53 PM, Grant Edwards wrote:
>> On 2021-05-20, Mats Wichmann wrote:
>>
>>> many fonts squish together repeated underscores in the display so it's
>>> hard to see this visually,
>>
>> Is it just me, or does it seem foolish to use such fonts for
>>
On 5/20/2021 2:53 PM, Grant Edwards wrote:
On 2021-05-20, Mats Wichmann wrote:
On 5/20/21 4:54 AM, Richard Damon wrote:
On 5/20/21 3:24 AM, Peter Otten wrote:
On 20/05/2021 06:00, Richard Damon wrote:
class GedcomHead(Gedcom0Tag):
"""GEDCOM 0 HEAD tag"""
def ___init___(self, *
On 2021-05-20, Mats Wichmann wrote:
> On 5/20/21 4:54 AM, Richard Damon wrote:
>> On 5/20/21 3:24 AM, Peter Otten wrote:
>>> On 20/05/2021 06:00, Richard Damon wrote:
>>>
class GedcomHead(Gedcom0Tag):
"""GEDCOM 0 HEAD tag"""
def ___init___(self, *, parent):
>>>
>>> An __
On 5/20/21 4:54 AM, Richard Damon wrote:
On 5/20/21 3:24 AM, Peter Otten wrote:
On 20/05/2021 06:00, Richard Damon wrote:
class GedcomHead(Gedcom0Tag):
"""GEDCOM 0 HEAD tag"""
def ___init___(self, *, parent):
An __init__ with three underscores; you must me joking ;)
Yes, that i
On 5/20/21 1:58 AM, Chris Angelico wrote:
> On Thu, May 20, 2021 at 2:02 PM Richard Damon
> wrote:
>> Given the following definition of classes, I am getting an unexpected
>> error of :
>>
>> TypeError: __init__() missing 2 required keyword-only arguments:
>> 'idcode' and 'tag'
>>
>> On the call
On 5/20/21 3:24 AM, Peter Otten wrote:
> On 20/05/2021 06:00, Richard Damon wrote:
>
>> class GedcomHead(Gedcom0Tag):
>> """GEDCOM 0 HEAD tag"""
>> def ___init___(self, *, parent):
>
> An __init__ with three underscores; you must me joking ;)
>
Yes, that is what I was missing, too many un
On 20/05/2021 06:00, Richard Damon wrote:
class GedcomHead(Gedcom0Tag):
"""GEDCOM 0 HEAD tag"""
def ___init___(self, *, parent):
An __init__ with three underscores; you must me joking ;)
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, May 20, 2021 at 2:02 PM Richard Damon wrote:
>
> Given the following definition of classes, I am getting an unexpected
> error of :
>
> TypeError: __init__() missing 2 required keyword-only arguments:
> 'idcode' and 'tag'
>
> On the call to create a GedcomHead in the call to GedcomHead()
Given the following definition of classes, I am getting an unexpected
error of :
TypeError: __init__() missing 2 required keyword-only arguments:
'idcode' and 'tag'
On the call to create a GedcomHead in the call to GedcomHead() in
Gedcom0Tag.add()
Code:
class GedcomTag:
"""Represents a Le
Stephen Rosen wrote at 2020-6-30 11:59 -0400:
>Hi all,
>
>I'm looking at a conflict between code sharing via inheritance and async
>usage. I would greatly appreciate any guidance, ideas, or best practices
>which might help.
>
>I'll speak here in terms of a toy exampl
Hi all,
I'm looking at a conflict between code sharing via inheritance and async
usage. I would greatly appreciate any guidance, ideas, or best practices
which might help.
I'll speak here in terms of a toy example, but, if anyone wants to look at
the real code, I'm working
e multiple inheritance with 'super ' it not
works. thanks for your help.
class Username:
def __init__(self, name, *args):
self.name= name
class Userfamily:
def __init__(self, family, *args):
self.family = family
class Person(
back error that said 'there is no such p.family
>> attribute'. although i use multiple inheritance with 'super ' it not
>> works. thanks for your help.
>>
>> ``` class Username: def __init__(self,name,*args): self.name
>> = name
&g
no such p.family
> attribute'. although i use multiple inheritance with 'super ' it not
> works. thanks for your help.
>
> ``` class Username: def __init__(self,name,*args): self.name
> = name
> class Userfamily: def __init__(self,family,*args):
HI guys this is my first post on python mailing lists ever and i glad to do
this.
my problem here is why this attribute is not recognize by python and it raise
an traceback error that said 'there is no such p.family attribute'. although i
use multiple inheritance with 'super
-Original Message-
From: Barry Scott
Sent: Tuesday, July 16, 2019 11:53 AM
To: Joseph L. Casale
Cc: python-list@python.org
Subject: Re: Class initialization with multiple inheritance
> And here is the MRO for LeftAndRight.
>
> >>> import m
> LeftAndRight.__ini
> On 16 Jul 2019, at 01:13, Joseph L. Casale wrote:
>
> I am trying to find explicit documentation on the initialization logic for a
> Base class when multiple exist. For the example in the documentation at
> https://docs.python.org/3/tutorial/classes.html#multiple-inheritance,
On 16/07/19 12:13 PM, Joseph L. Casale wrote:
I am trying to find explicit documentation on the initialization logic for a
Base class when multiple exist. For the example in the documentation at
https://docs.python.org/3/tutorial/classes.html#multiple-inheritance,
if Base1 and Base2 both
I am trying to find explicit documentation on the initialization logic for a
Base class when multiple exist. For the example in the documentation at
https://docs.python.org/3/tutorial/classes.html#multiple-inheritance,
if Base1 and Base2 both themselves inherited from the same base class,
only
On Sat, Mar 30, 2019 at 7:08 PM Arup Rakshit wrote:
>
> Thanks Chris and Dieter. I think I got it. It seems it follows the __mro__ of
> the caller class, not the current class __mro_.
That is correct. It is the object that has an MRO, and it's that
object's MRO that matters to super.
ChrisA
--
Thanks Chris and Dieter. I think I got it. It seems it follows the __mro__ of
the caller class, not the current class __mro_.
if __name__ == '__main__':
print('MRO of SortedIntList {}'.format(SortedIntList.__mro__))
print('MRO of IntList {}'.format(IntList.__mro__))
# MRO of SortedIntLi
Hello DL,
I am using Python3.
Thanks,
Arup Rakshit
a...@zeit.io
> On 30-Mar-2019, at 6:58 AM, DL Neil wrote:
>
> Arup,
>
> There is a minefield here. Are you using Python 2 or 3?
>
> --
> Regards =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.o
Arup Rakshit writes:
> I basically had defined 4 classes. SimpleList be the base class for all the
> other 3 classes. SortedList and IntList both being the child of the base
> class SimpleList. They have a single inheritance relationship. Now I have the
> last class called SortedI
On Fri, Mar 29, 2019 at 11:54 PM Arup Rakshit wrote:
>
> Now when I call the add method on the SortedIntList class’s instance, I was
> expecting super.add() call inside the IntList class add method will dispatch
> it to the base class SimpleList. But in reality it doesn’t, it rather
> forwards
Arup,
There is a minefield here. Are you using Python 2 or 3?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
I basically had defined 4 classes. SimpleList be the base class for all the
other 3 classes. SortedList and IntList both being the child of the base class
SimpleList. They have a single inheritance relationship. Now I have the last
class called SortedIntList which has multiple inheritance
> ChrisA
Yes, that works. Thank you all for your help. -->
class A:
def __init__(self):
self.number = 1
def A_biginc(self):
self.number += 107
A.biginc = A_biginc
class B(A):
def __init__(self):
super().__init__()
print("making a B")
def B_biginc(self):
super(B,self).bi
On Thu, Aug 16, 2018 at 6:00 AM, thomas.lynch--- via Python-list
wrote:
> Appreciate some help in how in Python a person can add some external methods
> to existing classes in the presence of simple one level inheritance. Here is
> an example stripped down to the shiny brass tacks:
&g
You really can't, and shouldn't. The super() helper relies on information
that exists inside the class definition and which is not available simply
at runtime by virtue of being attached to the class.
Besides, modifying classes externally is generally considered a bad idea.
Maybe you could accompl
> # this prints for me when I run this in 3.6
excuse me, that is an extraneous comment from a cut and paste, in fact the
example never makes it to the prints, as shown in the transcript just below the
source code
--
https://mail.python.org/mailman/listinfo/python-list
Appreciate some help in how in Python a person can add some external methods to
existing classes in the presence of simple one level inheritance. Here is an
example stripped down to the shiny brass tacks:
class A:
def __init__(self):
self.number = 1
def A_biginc(self):
self.number
On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> Ruby is fundamentally _opposed_ to the idea of multiple inheritance --
> as MI is rife with issues (technical, practical, and intuitive in
> nature) and thus, not a wise solution -- but you would have known that
> St
3/glossary.html>, but with the
> caveat that many flaws have been found in recent years.
>
>> However, in books about Python and other languages, I have also seen the
>> terms:
>>
>> base class & derived class
>> parent class & child class
>>
ms:
>
> base class & derived class
> parent class & child class
> superclass & subclass
The only term I take issue with there is “superclass”. In a
multiple-inheritance system, such as provided by Python, the superclass
is *not* necessarily the base class. See this article f
I'm doing some writing for an upcoming course on OOP using Python.
I have been doing OOP programming for many years in many different languages,
and I want make sure that I'm using the appropriate terminology in Python. I'd
like to know if there are "official" or even standard terms that are
Steve D'Aprano writes:
> Good way:
>
> Foreigner speaking English as their second language:
> "Who is the father of this class?"
>
> Native English speaker:
> "The father is 'object', but in English we would normally ask
> 'what is the parent?' instead."
Of the three scenario
On Fri, 8 Sep 2017 07:03 pm, Ben Finney wrote:
>> Who is the father of ExampleClass1 ?
>
> No-one, since classes do not have gender. (The convention is to use the
> gender-neutral “parent” to refer to that relationship.)
Possibly not the case in Russia. Besides, words have gender in many langua
Andrej Viktorovich writes:
> I found several class creation samples:
>
> class ExampleClass1:
>
> class ExampleClass2(object):
>
>
> What is difference between them?
Very little difference.
In Python 3, both create classes that inherit from one other class,
‘object’.
In Python 2, the first cre
On 2017-09-08 10:17, Andrej Viktorovich wrote:
> Hello
>
> I found several class creation samples:
>
> class ExampleClass1:
>
> class ExampleClass2(object):
>
>
> What is difference between them? Who is the father of ExampleClass1 ?
>
In Python 3, unless you've redefined "object", these are
Hello
I found several class creation samples:
class ExampleClass1:
class ExampleClass2(object):
What is difference between them? Who is the father of ExampleClass1 ?
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, 24 Apr 2017 10:10 pm, id23...@gmail.com wrote:
> I do not quite understand how inheritance works in Python.
[...]
> class mainCL():
> def __init__(self):
> self.path1 = "/a"
> self.path2 = "/b"
>
> class se
I do not quite understand how inheritance works in Python.
I use python 3.6.1.
Let say I have a directory structure /a, /b. These two paths described
in main class.
The second class describes additional structure in one of the main
structures, say on /b and it should look like this:
/b/id1
/b
c. by e.g. floats in exactly the same way as numpy.
What I can't immediately see is a clean way of doing this with
delegation. But I'm unsure that inheritance is the best way to go (the
class will be very lightweight compared to numpy arrays). Any advice
welcome. I'm currently using
"Frank Millman" wrote in message news:o5hnbq$q36$1...@blaine.gmane.org...
"Frank Millman" wrote in message news:o5hlh4$1sb$1...@blaine.gmane.org...
>
> If you are saying -
> for item in list:
> print(item)
>
> you can say instead -
> for item in list:
> print(str(item))
>
"Frank Millman" wrote in message news:o5hlh4$1sb$1...@blaine.gmane.org...
If you are saying -
for item in list:
print(item)
you can say instead -
for item in list:
print(str(item))
This is not correct, sorry.
print(item) will automatically print the string representat
"David D" wrote in message
news:4f0680eb-2678-4ea2-b622-a6cd5a19e...@googlegroups.com...
I am creating a parent class and a child class. I am inheriting from the
parent with an additional attribute in the child class. I am using
__str__ to return the information. When I run > the code, it
Hi,
On 15/01/17 19:58, David D wrote:
I am creating a parent class and a child class. I am inheriting from
the parent with an additional attribute in the child class. I am
using __str__ to return the information. When I run the code, it
does exactly what I want, it returns the __str__ informa
On Mon, Jan 16, 2017 at 6:58 AM, David D wrote:
> I am creating a parent class and a child class. I am inheriting from the
> parent with an additional attribute in the child class. I am using __str__
> to return the information. When I run the code, it does exactly what I want,
> it returns
I am creating a parent class and a child class. I am inheriting from the
parent with an additional attribute in the child class. I am using __str__ to
return the information. When I run the code, it does exactly what I want, it
returns the __str__ information. This all works great.
BUT
1)
>
> 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
got introduced into the MRO as a result
> of someone else subclassing your class.
>
> So when you make a super call, you really have *no idea*
> what it's going to call.
That's the nature of inheritance in a MI world. If you try to specify a
particular superclass manually,
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
diamonds
when you use multiple inheritance.
> there is no need to use super.
Except then you are precluding others from integrating your classes into
their class hierarchies.
> Explicit inherited method calls, done correctly, will
> work fine.
>
> The only downside is that if
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
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
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 nex
_(self, spam, eggs=4, beans=None, *args, **kwargs):
> self.eggs = eggs
> self.beans = beans
> super().__init__(spam, *args, **kwargs)
Except that since we're discussing design for multiple inheritance,
the positional argument "spam" is inappropriate. All argum
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,
d to share the same parameter?
>
Is the problem that the attribute or parameter has the same name in both
base classes, but has different meanings in each?
If so, and you're in control of every class in the inheritance hierarchy,
perhaps you can come up with more specific names so that the bas
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
may be wrong.
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. And, what's more, you can't know when writing a class whether
i
;t use it until you're using Python 3.6
> or higher.
Yes, I know. I do this for fun, not for money.
> 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.
> Perhaps you are unaware
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
similar.
> The problem is obvious:
Heh :-) There's nothing obvious about multiple inheritance problems.
> because of the method resolution order, the
> super call in Observable.__init__ will try to call BaseDesktop.__init__
> without arguments, but that constructor has needs to
thon's
classes implement the constructor as ‘__new__’, and you very rarely need
to bother with that.)
For the reasons you describe (among others), participating in multiple
inheritance is tricky.
As described in numerous articles, for example
https://rhettinger.wordpress.com/2011/05/26/super
Today I come across this problem for the N+1st time. Here are some
classes for the example:
class Observable:
"""Implements the observer-observable pattern."""
def __init__(self):
# initialization code here...
super(Observable, self).__init__()
class AppServerSessionMixi
On 01/01/2016 19:16, PythonLearner wrote:
Hello All,
I'm new to this group.
I'm looking for examples for Multiple and Multilevel Inheritance without the
use of super().
Thanks
An Avid Python Learner
Please tell us what you're trying to achive, as without super() you'll
b
Hello All,
I'm new to this group.
I'm looking for examples for Multiple and Multilevel Inheritance without the
use of super().
Thanks
An Avid Python Learner
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Aug 28, 2015 at 1:02 PM, Steven D'Aprano wrote:
> On Fri, 28 Aug 2015 12:33 am, Chris Angelico wrote:
>
>> On Thu, Aug 27, 2015 at 10:59 PM, Steven D'Aprano
>> wrote:
>>> On Thu, 27 Aug 2015 09:14 am, Chris Angelico wrote:
>>>
On Thu, Aug 27, 2015 at 9:12 AM, Chris Angelico
wro
On Fri, 28 Aug 2015 12:33 am, Chris Angelico wrote:
> On Thu, Aug 27, 2015 at 10:59 PM, Steven D'Aprano
> wrote:
>> On Thu, 27 Aug 2015 09:14 am, Chris Angelico wrote:
>>
>>> On Thu, Aug 27, 2015 at 9:12 AM, Chris Angelico
>>> wrote:
Or is there a magic __isinstance__
>>>
>>> Argh, keyed th
On Thu, Aug 27, 2015 at 10:59 PM, Steven D'Aprano wrote:
> On Thu, 27 Aug 2015 09:14 am, Chris Angelico wrote:
>
>> On Thu, Aug 27, 2015 at 9:12 AM, Chris Angelico wrote:
>>> Or is there a magic __isinstance__
>>
>> Argh, keyed the wrong thing and sent the post prematurely. Meant to say:
>>
>> Or
On Thu, 27 Aug 2015 09:14 am, Chris Angelico wrote:
> On Thu, Aug 27, 2015 at 9:12 AM, Chris Angelico wrote:
>> Or is there a magic __isinstance__
>
> Argh, keyed the wrong thing and sent the post prematurely. Meant to say:
>
> Or is there a magic __instancecheck__ method somewhere that I'm not
1 - 100 of 1333 matches
Mail list logo
