Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #109286 > unrolled thread

Multiple inheritance, super() and changing signature

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-05-31 18:10 +0200
    Re: Multiple inheritance, super() and changing signature Steven D'Aprano <steve@pearwood.info> - 2016-06-01 12:18 +1000
      Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 14:10 +0200
        Re: Multiple inheritance, super() and changing signature Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-04 13:06 +1200
          Re: Multiple inheritance, super() and changing signature Steven D'Aprano <steve@pearwood.info> - 2016-06-04 12:51 +1000
            Re: Multiple inheritance, super() and changing signature Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-04 23:50 +1200
          Re: Multiple inheritance, super() and changing signature Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-03 23:05 -0600
            Re: Multiple inheritance, super() and changing signature Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-04 23:52 +1200
              Re: Multiple inheritance, super() and changing signature Steven D'Aprano <steve@pearwood.info> - 2016-06-04 23:46 +1000
                Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-04 16:42 +0200
      Re: Multiple inheritance, super() and changing signature Ben Finney <ben+python@benfinney.id.au> - 2016-06-03 22:21 +1000
        Re: Multiple inheritance, super() and changing signature Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-04 13:10 +1200
      Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 14:14 +0200
      Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 14:57 +0200
      Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 16:06 +0200
      Re: Multiple inheritance, super() and changing signature Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-03 08:39 -0600
      Re: Multiple inheritance, super() and changing signature Michael Selik <michael.selik@gmail.com> - 2016-06-03 15:33 +0000
      Re: Multiple inheritance, super() and changing signature Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 17:59 +0200
      Re: Multiple inheritance, super() and changing signature Michael Selik <michael.selik@gmail.com> - 2016-06-03 16:28 +0000
      Re: Multiple inheritance, super() and changing signature Ben Finney <ben+python@benfinney.id.au> - 2016-06-04 06:16 +1000
      Re: Multiple inheritance, super() and changing signature Ben Finney <ben+python@benfinney.id.au> - 2016-06-04 06:19 +1000
      Re: Multiple inheritance, super() and changing signature Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-03 15:53 -0600
      Re: Multiple inheritance, super() and changing signature Ben Finney <ben+python@benfinney.id.au> - 2016-06-04 10:44 +1000

Page 2 of 2 — ← Prev page 1 [2]

#109438

Nagy László Zsolt <gandalf@shopzeus.com> 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 different things in different
sub-classes meant that instances of those sub-classes had difficulty
substituting for the superclass. Interrogating the design against the
LSP reveals that.

> Problem solved. Thank you for all your help!
> Cooperative classes are fantastic! :-)

I'm glad you discovered them :-)

-- 
 \       “Truth is stranger than fiction, but it is because fiction is |
  `\     obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)                                          _Following the Equator_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#109440

On Fri, Jun 3, 2016 at 2:16 PM, Ben Finney <ben+python@benfinney.id.au> 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.
>
>     class LoremIpsum:
>         def __init__(self, spam, *args, **kwargs):
>             do_something_important_with(spam)
>             super().__init__(*args, **kwargs)
>
>     class DolorSitAmet(LoremIpsum):
>         def __init__(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 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
actual next class might not expect spam to be the first positional
argument.

[toc] | [prev] | [next] | [standalone]

#109447

Ian Kelly <ian.g.kelly@gmail.com> 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
> actual next class might not expect spam to be the first positional
> argument.

You're right. That also allows us to stop handling unknown positional
arguments.

This does make it troublesome to design the function signature though,
and I can see why people balk at how to deal with the semantics of
‘super’ in Python 2::

    class LoremIpsum(object):
        def __init__(self, **kwargs):
            spam = kwargs.pop('spam')
            do_something_important_with(spam)
            super(LoremIpsum, self).__init__(**kwargs)

    class DolorSitAmet(LoremIpsum):
        def __init__(self, **kwargs):
            self.eggs = kwargs.pop('eggs')
            self.beans = kwargs.pop('beans')
            super(DolorSitAmet, self).__init__(**kwargs)

That's awful :-( because the initialiser's signature no longer shows any
sign of which parameters matter for this class.

It also sucks to need ‘dict.pop('name')’, instead of just ‘name’.


Keyword-only parameters make this easier and clearer::

    class LoremIpsum:
        def __init__(self, *, spam, **kwargs):
            spam = kwargs.pop('spam')
            do_something_important_with(spam)
            super().__init__(**kwargs)

    class DolorSitAmet(LoremIpsum):
        def __init__(self, *, eggs=4, beans=None, **kwargs):
            self.eggs = eggs
            self.beans = beans
            super().__init__(**kwargs)

I guess that's yet another reason to advocate Python 3 for all new code.

-- 
 \          “One time a cop pulled me over for running a stop sign. He |
  `\        said, ‘Didn't you see the stop sign?’ I said, ‘Yeah, but I |
_o__)                don't believe everything I read.’” —Steven Wright |
Ben Finney

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web