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

Groups > comp.lang.python > #65226

Re: __init__ is the initialiser

Show all headers | View raw

> On 01/02/2014 14:40, Roy Smith wrote:
> > In article <mailman.6275.1391257695.18130.python-list@python.org>,
> >   Ned Batchelder <ned@nedbatchelder.com> wrote:
> >
> >> The existence of __new__ is an
> >> advanced topic that many programmers never encounter.  Taking a quick
> >> scan through some large projects (Django, edX, SQLAlchemy, mako), the
> >> ratio of __new__ implementations to __init__ implementations ranges from
> >> 0% to 1.5%, which falls into "rare" territory for me.
> >
> >  From our own codebase:
> >
> > $ find . -name '*.py' | xargs grep 'def.*__new__' | wc -l
> > 1
> > $ find . -name '*.py' | xargs grep 'def.*__init__' | wc -l
> > 228
> >
> > Doing the same searches over all the .py files in our virtualenv, I get
> > 2830 (__init__) vs. 50 (__new__).

In article <mailman.6280.1391267257.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> You could remove all 228 __init__ and still get your code to work by 
> scattering object attributes anywhere you like, something I believe you 
> can't do in C++/Java.

Why not?  Here's a simple C++ program which uses a constructor:

#include <stdio.h>

class Foo {
public:
    int i;

    Foo() : i(42) {}
};

int main(int, char**) {
    Foo foo;
    printf("foo.i = %d\n", foo.i);
}

If I wanted to, I could remove the constructor and still "get my code to 
work by scattering object attributes anywhere I like":

#include <stdio.h>

class Foo {
public:
    int i;
};

int main(int, char**) {
    Foo foo;
    foo.i = 42;
    printf("foo.i = %d\n", foo.i);
}

> I doubt that you could remove the single __new__ and get your code to work.

Perhaps.  Looking at our own code, the one place we use __new__ is in a 
metaclass, which I think pretty well reinforces Ned's assertion that 
__new__ is an advanced topic.

Back to comp.lang.python | Previous | Next — Previous in thread | Next 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