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

Groups > comp.lang.python > #65299

Re: __init__ is the initialiser

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 1 February 2014 14:42, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> On Fri, 31 Jan 2014 14:52:15 -0500, Ned Batchelder wrote:
>
> (In hindsight, it was probably a mistake for Python to define two create-
> an-object methods, although I expect it was deemed necessary for
> historical reasons. Most other languages make do with a single method,
> Objective-C being an exception with "alloc" and "init" methods.)
>

I disagree. In nearly every language I've used which only has single-phase
construction, I've wished for two-phase construction. By the time you get
to __init__ you know the following things about the instance:

1. It is a complete instance of the subclass - there's no part of the
structure that is invalid to access (of course, many attributes might not
yet exist).

2. Calling a method from __init__ will call the subclass' method. This
allows subclasses to hook into the initisation process by overriding
methods (of course, the subclass will need to ensure it has initialised all
the state it needs). This is generally not allowed in languages with
single-phase construction because the object is in an intermediate state.

For example,  in C++ the vtable is for the class currently being
constructed, not the subclass, so it will always call the current class'
implementation of the method.

In Java you can actually call the subclass' implementation, but in that
case it will call the subclass method before the subclass constructor is
actually run, meaning that instance variables will have their default
values (null for objects). When the base class constructor is eventually
run the instance variables will be assigned the values in the class
definition (replacing anything set by the subclass method call).

Tim Delaney

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: __init__ is the initialiser Ned Batchelder <ned@nedbatchelder.com> - 2014-01-31 14:52 -0500
  Re: __init__ is the initialiser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-01 03:42 +0000
    Re: __init__ is the initialiser Chris Angelico <rosuav@gmail.com> - 2014-02-01 15:35 +1100
      Re: __init__ is the initialiser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-01 05:51 +0000
        Re: __init__ is the initialiser Ethan Furman <ethan@stoneleaf.us> - 2014-02-01 00:28 -0800
    Re: __init__ is the initialiser Ethan Furman <ethan@stoneleaf.us> - 2014-01-31 20:55 -0800
    Re: __init__ is the initialiser Ned Batchelder <ned@nedbatchelder.com> - 2014-02-01 07:28 -0500
      Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-01 09:40 -0500
        Re: __init__ is the initialiser Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-01 15:07 +0000
          Re: __init__ is the initialiser Roy Smith <roy@panix.com> - 2014-02-01 11:17 -0500
    Re: __init__ is the initialiser Tim Delaney <timothy.c.delaney@gmail.com> - 2014-02-02 07:09 +1100
      Re: __init__ is the initialiser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-02 01:28 +0000
    Re: __init__ is the initialiser Ben Finney <ben+python@benfinney.id.au> - 2014-02-02 15:27 +1100
    Re: __init__ is the initialiser Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-03 12:38 +1300
      Re: __init__ is the initialiser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-03 00:33 +0000
        Re: __init__ is the initialiser Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-04 12:47 +1300
    Re: __init__ is the initialiser Tim Delaney <timothy.c.delaney@gmail.com> - 2014-02-03 11:02 +1100

csiph-web