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.
>
> > What happens when Top is initi
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 happen, and when you
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 twice.
No:
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 written in the
> pre-super() e
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. The classe
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 them ini
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 Left a
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
-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
ntList which has multiple inheritance relationship
> with IntList and SortedList. The classes looks like:
>
> class SimpleList:
> ...
> def add(self, item):
> self._items.append(item)
> ...
>
> class SortedList(SimpleList):
> ...
> de
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
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
>
> 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
r class inherits from
K, doesn't mean that you should be calling K's methods. Until you (generic
you) come to terms with that, you're going to struggle with MI regardless
of what you do.
It might help to read Michele Simionato's articles about super, multiple
inheritance and relate
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
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 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,
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
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 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
On Thu, 27 Aug 2015 09:12:55 +1000, Chris Angelico wrote:
>
> You're omitting some context here, but after poking around with your
> module a bit, I'm guessing you created bf somewhat thus?
>
bf = bitfield.make_bf("bf", (("asdf",bitfield.c_uint,2),))
bf
>
bf.__mro__
> (, , '_ctyp
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 aware of?
ChrisA
--
https://mail.python.org/mailman/listinfo/
On Thu, Aug 27, 2015 at 7:21 AM, Rob Gaddi
wrote:
> I'm running into some strangeness trying to work with the bitfield module
> from my ctypes-bitfield package (on PyPi). I'm trying to use isinstance
> (), and it's kinda sorta lying to me.
>
> - IPython session (Python 3.4 under Linux) --
.__bases__
Out[651]: (_ctypes.Union, bitfield.Bitfield)
In [652]: bf.__bases__[1]
Out[652]: bitfield.Bitfield
In [653]: bf.__bases__[1] is bitfield.Bitfield
Out[653]: True
---
Is there an issue with isinstance and multiple inheritance? Conversely
is there
itfield
Out[653]: True
---
Is there an issue with isinstance and multiple inheritance? Conversely
is there an issue with isinstance and ctypes derived classes (Bitfield
isn't, but Bitfield is a mixin that always works with Unions) I know
On 12/17/2012 4:14 AM, Ian Kelly wrote:
On Sun, Dec 16, 2012 at 9:30 PM, Nick M. Daly wrote:
It's very unlikely that multiple inheritance would go horribly wrong, as
long as classes adopt class-specific argument naming conventions.
However, ever since bug 1683368 [0] was fixed, it&
On Sun, Dec 16, 2012 at 9:30 PM, Nick M. Daly wrote:
> It's very unlikely that multiple inheritance would go horribly wrong, as
> long as classes adopt class-specific argument naming conventions.
> However, ever since bug 1683368 [0] was fixed, it's now impossible to
> cl
If you're short on time, the subject's all you need to read. It seems
like it would always be the right thing to do, when the sub-class
specifically requests it.
It's very unlikely that multiple inheritance would go horribly wrong, as
long as classes adopt class-specific
u say it does.
> Please test your code before posting and ensure it actually fails the way
> you expect.
>
> It is perfectly fine to use multiple inheritance in the way you show.
> Here is an even simpler example:
>
> py> class Spam(object):
> ... pass
> ...
> py
y fails the way
you expect.
It is perfectly fine to use multiple inheritance in the way you show.
Here is an even simpler example:
py> class Spam(object):
... pass
...
py> class Ham(list, Spam):
... pass
...
py>
py> h = Ham([1, 2, 3])
py>
And no exception is
On Sat, 07 Jan 2012 22:08:22 -0800, 8 Dihedral wrote:
[...]
> The class is defined in a silly way.
> In python declaring a class with only trivial properties added is not
> very python at all.
The example given looks like a Mixin class, which is perfectly acceptable
in Python.
--
Steven
A list is a container.
Chris Angelico於 2012年1月8日星期日UTC+8上午9時27分06秒寫道：
> On Sun, Jan 8, 2012 at 12:16 PM, lars van gemerden
> wrote:
> > Hello,
> >
> > I have an error message i do not understand:
> >
> > My code is in essence:
> >
> > b = B([1,2,3,4])
> >
> > error:
> > b = B([0,1,2,3,4])
>
On Sun, Jan 8, 2012 at 12:16 PM, lars van gemerden wrote:
> Hello,
>
> I have an error message i do not understand:
>
> My code is in essence:
>
> b = B([1,2,3,4])
>
> error:
> b = B([0,1,2,3,4])
> TypeError: B() takes exactly 2 arguments (1 given)
Your code doesn't quite match your error mess
Hello,
I have an error message i do not understand:
My code is in essence:
class A(object):
#no __new__ or __init__
def meth1(self, args):
#some code
def meth2(self, args):
#some code
class B(list, A)
pass
b = B([1,2,3,4])
error:
Traceback (most recent call last):
On 5/4/2011 11:36 AM, Ethan Furman wrote:
Raymond Hettinger wrote:
I'm writing-up more guidance on how to use super() and would like to
point at some real-world Python examples of cooperative multiple
inheritance.
Multiple inheritance in Python is so badly designed that it
probably s
Raymond Hettinger wrote:
I'm writing-up more guidance on how to use super() and would like to
point at some real-world Python examples of cooperative multiple
inheritance.
Don't know if you are still looking for examples, but I recently came
across a thread in Python-Dev which had
On 02/09/2011 08:40 PM, Carl Banks wrote:
I explained why in my last post; there's a bunch of reasons.
Generally you can't assume someone's going to go through the type
structure to find the object's dict, nor can you expect inherited
methods to always use the derived class's type structure (some
ues). Even if you are careful to avoid such usage, the Python
interpreter can't be sure. So it has to check for layout conflicts,
and these checks would become very complex if it allowed dict and
weakreflist to appear in different locations in the layout (it's have
to check a lot mo
On 02/09/2011 05:02 PM, Carl Banks wrote:
On Feb 9, 1:14 pm, Rouslan Korneychuk wrote:
Each Python class is a wrapper for a C++ class.
Also, if you want my opinion (you probably don't after you've already
gone to so much trouble, but here it is anyway):
No, your opinion is quite welcome.
? If so, then it
wouldn't matter what the base classes look like.
"some_data" a proper subset of "some_other_data", right? (If it isn't
you have worse problems than dict and weakreflist.)
Not at all. The point of this, is to allow C++ multiple inheritance to
be m
On Feb 9, 1:14 pm, Rouslan Korneychuk wrote:
> Each Python class is a wrapper for a C++ class.
Also, if you want my opinion (you probably don't after you've already
gone to so much trouble, but here it is anyway):
It's not worth it to mimic the C++ type hierarchy in Python. Just
wrap each C++ c
On Feb 9, 1:14 pm, Rouslan Korneychuk wrote:
> On 02/09/2011 02:42 PM, Carl Banks wrote:
> > This is the only case I can think of where the
> > layout conflict would be caused by a type setting tp_dictoffset.
>
> No, actually I have code that is roughly equivalent to the following
> pseudocode:
>
ffset). This is
pertaining to the C API.
I noticed that when using multiple inheritance, I need a common base
class or I get an "instance lay-out conflict" error (my program already
deals with the issue of having a varying layout), but the error also
happens when the derived classes h
ning to the C API.
>
> I noticed that when using multiple inheritance, I need a common base
> class or I get an "instance lay-out conflict" error (my program already
> deals with the issue of having a varying layout), but the error also
> happens when the derived classes have
I'm working on a program that automatically generates C++ code for a
Python extension and I noticed a few limitations when using the weaklist
and instance dictionaries (tp_weaklistoffset and tp_dictoffset). This is
pertaining to the C API.
I noticed that when using multiple inheritan
> So far, the only situation I can find where method names necessarily
> overlap is for the basics like __init__(), close(), flush(), and
> save() where multiple parents need to have their own initialization
> and finalization.
One other possibility is subclasses of the JSONEncoder class. For
exam
Most of the examples presented here can use the "decorator pattern" instead.
Especially the window system
On Mon, Nov 29, 2010 at 5:27 PM, Gregory Ewing
wrote:
> Paul Rubin wrote:
>
> The classic example though is a window system, where you have a "window"
>> class, and a "scroll bar" class, an
Paul Rubin wrote:
The classic example though is a window system, where you have a "window"
class, and a "scroll bar" class, and a "drop-down menu" class, etc. and
if you want a window with a scroll bar and a drop-down menu, you inherit
from all three of those classes.
Not in any GUI library I'
2010/11/24 Raymond Hettinger :
> I'm writing-up more guidance on how to use super() and would like to
> point at some real-world Python examples of cooperative multiple
> inheritance.
>
> Google searches take me to old papers for C++ and Eiffel, but that
> don't seem t
x27;m writing-up more guidance on how to use super() and would like to
point at some real-world Python examples of cooperative multiple
inheritance.
Google searches take me to old papers for C++ and Eiffel, but that
don't seem to be relevant to most Python programmers (i.e. a
WalkingMenu examp
On Nov 28, 2:01 pm, m...@distorted.org.uk (Mark Wooding) wrote:
> Steve Holden writes:
> > It isn't. Even inheritance itself isn't as useful as it at first
> > appears, and composition turns out in practice to be much more useful.
> > That goes double for multip
ly and did try it for super().
However, you still need to drill into many of the hits manually,
because it is difficult to disambiguate a single inheritance use
of super() (which is very common) from a design with cooperative
multiple inheritance. You have to read a lot of code and can still
come
up empty
* Steve Holden wrote:
> Even inheritance itself isn't as useful as it at first
> appears, and composition turns out in practice to be much more useful.
> That goes double for multiple inheritance.
Amen.
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~})
xamples above: connection
pooling and most of the wsgi middleware are still to be ported,
`weights()` is missing, etc.
Hope it helps.
Thanks,
Kirill
On 11/24/2010 03:08 PM, Raymond Hettinger wrote:
I'm writing-up more guidance on how to use super() and would like to
point at some real-world
Steve Holden writes:
> It isn't. Even inheritance itself isn't as useful as it at first
> appears, and composition turns out in practice to be much more useful.
> That goes double for multiple inheritance.
Composition /with a convenient notation for delegation/ works fairly
On Nov 24, 11:08 pm, Raymond Hettinger wrote:
> I'm writing-up more guidance on how to use super() and would like to
> point at some real-world Python examples of cooperative multiple
> inheritance.
>
> Google searches take me to old papers for C++ and Eiffel, but that
> do
On 11/27/2010 4:34 PM, Steven D'Aprano wrote:
[...]
> The problem isn't writing documentation for the feature, but coming up
> with real-world use-cases. The documentation for super and the MRO is
> extensive and detailed. It's also complicated, because multiple
>
afterthoughts seems like a contradiction.
> Smalltalk went a bit too far in the other direction; the
> "everything is an object" mindset was overdoing it.
>
> Python is reasonably well balanced in the object area.
> Everything isn't an object.
I don't und
> Common Lisp, Dylan, Scheme, and variants of Smalltalk -- you might
> > got on much better.
>
>Ah, fanboys.
Not exactly. I collect programming languages like some people collect
postage stamps; it gives one a useful perspective. I mentioned those
languages because they seem mo
1 - 100 of 399 matches
Mail list logo
