On 06/16/2015 07:55 PM, Dr. John Q. Hacker wrote:
> Interesting. This brings up an issue another poster brought up: In my
> usage of the term "parent", I use it to mean the class that is a product of
> object composition:
>
> class Parent(child1, child2): pass
Hmm. This is a definition of "par
On Sun, May 24, 2015 at 6:11 AM, Steven D'Aprano
wrote:
> On Sun, 24 May 2015 11:53 am, Dr. John Q. Hacker wrote:
> But, frankly, what you describe is more likely to be a weakness of multiple
> inheritance and mixins, one which should be avoided. One attempt to avoid
> this problem is with traits
On Sun, 24 May 2015 11:53 am, Dr. John Q. Hacker wrote:
> The post on "different types of inheritence..." brought up a thought.
>
> Let's say, I'm adding flexibility to a module by letting users change
> class behaviors by adding different mix-in classes.
>
On Sat, May 23, 2015 at 7:53 PM, Dr. John Q. Hacker
wrote:
> The post on "different types of inheritence..." brought up a thought.
>
> Let's say, I'm adding flexibility to a module by letting users change class
> behaviors by adding different mix-in classes.
>
On Sat, May 23, 2015, at 21:53, Dr. John Q. Hacker wrote:
> What should happen when there's a name collision on method names between
> mix-ins? Since they're mix-ins, it's not presumed that there is any
> parent
> class to decide. The proper thing would seem to call each method in the
> order th
The post on "different types of inheritence..." brought up a thought.
Let's say, I'm adding flexibility to a module by letting users change class
behaviors by adding different mix-in classes.
What should happen when there's a name collision on method names between
mix-in
