Proposal: default __init__

[Andrew Dalke]

Steve Holden wrote:
>However, when using other people's code, a default null __init__() might
>be helpful.  Although, of course, you would still get similar problems
>if you later decided that the __init__() method of an object you had
>defined yourself needed to change its interface, for example adding
>parameters: all calls to __init__() would then need to be edited.

That isn't always a problem.  For example, suppose you extended the
number of parameters but added them after the existing parameters and
used appropriate default arguments for those new ones.  Then you can
change the API but keep backwards compatibility.

On the other hand, if the interface is not backwards compatible, I
would like code to break.  As it stands now, if you have

class A:
  pass

class B(A):
  def __init__(self, data):
    self.data = data

and replaced A with

class A:
  def __init__(self, username, password):
    self.username = username
    self.password = password

you can still make a B(), even though I would like it to fail, unless told
otherwise.

The problem is that the current style of "not calling __init__ because it
doesn't exist" is written the same as the "not told otherwise" case.

Instead, if I could call A's __init__ even when it doesn't have an
explicit __init__, then I could write

class B(A):
  def __init__(self, data):
    A.__init__(self)
    self.data = data

and be safe in the knowledge that if A's __init__ changed then my code
would break at the point, and not latter due to some secondary,
consequential
effect.

                    Andrew
                    dalke at acm.org