__init__() not called automatically

[Sriek]

hi,
i come from a c++ background. i ws happy to find myself on quite
familiar grounds with Python. But, what surprised me was the fact that
the __init__(), which is said to be the equivlent of the constructor in
c++, is not automatically called. I'm sure there must be ample reason
for this. I would like to know why this is so? This is my view is more
burden on the programmer.
Similarly, why do we have to explicitly use the 'self' keyword
everytime?

Every kind of help would be welcome.

[Tim Leslie]

On 25 May 2005 21:31:57 -0700, Sriek <sc*******@gmai l.com> wrote:

hi,
i come from a c++ background. i ws happy to find myself on quite
familiar grounds with Python. But, what surprised me was the fact that
the __init__(), which is said to be the equivlent of the constructor in
c++, is not automatically called. I'm sure there must be ample reason
for this. I would like to know why this is so? This is my view is more
burden on the programmer.

class C: .... def __init__(self): print "Hello"
.... c = C()

Hello

This looks like __init__ being called automatically to me. Are you
doing something different?
Similarly, why do we have to explicitly use the 'self' keyword
everytime?
http://www.python.org/doc/faq/genera...ions-and-calls

Every kind of help would be welcome.
No worries,

Tim

--
http://mail.python.org/mailman/listinfo/python-list

[Paul McNett]

Sriek wrote:

hi,
i come from a c++ background. i ws happy to find myself on quite
familiar grounds with Python. But, what surprised me was the fact that
the __init__(), which is said to be the equivlent of the constructor in
c++, is not automatically called.
What do you mean by automatically? :

Python 2.4.1 (#2, May 5 2005, 09:45:41)
[GCC 4.0.0 20050413 (prerelease) (Debian 4.0-0pre11)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

class A(object): .... def __init__(self):
.... print "in __init__"
.... a = A()

in __init__

So __init__ is definitely called upon instantiation. It is true that if
you derive from A and override __init__, A.__init__ won't be called
unless done so explicitly like:

class B(A):
def __init__(self):
print "in B.__init__()"
super(B, self).__init__( )
I'm sure there must be ample reason
for this. I would like to know why this is so? This is my view is more
burden on the programmer.
It isn't that much practical burden, and IMO it makes perfect sense.
When you override a method of a class, you want to have to explicitly
call superclass code, not have it run automatically, else you lose
control of the flow.

Similarly, why do we have to explicitly use the 'self' keyword
everytime?
This is closer to a wart, IMO, but once you've used Python for a while
you'll come to understand why this is so. Basically, everything in
Python is either a namespace or a name in a namespace. In the case of
the self reference which Python sends as the first arg automatically,
the method needs to bind that to a local name which is, by convention
only, 'self'.

Every kind of help would be welcome.

You've found the right place to hang out. Welcome!
--
pkm ~ http://paulmcnett.com

[Sriek]

Tim pointed out rightly that i missed out the most crucial part of my
question.
i should have said that __init__() is not called automatically only for
the inheritance hierarchy. we must explicitly call all the base class
__init__() fuctions explicitly.
i wanted a reason for that.
Thanks Tim.

[Steven Bethard]

Paul McNett wrote:

Sriek wrote:

i come from a c++ background. i ws happy to find myself on quite
familiar grounds with Python. But, what surprised me was the fact that
the __init__(), which is said to be the equivlent of the constructor in
c++, is not automatically called.

[snip]
It is true that if
you derive from A and override __init__, A.__init__ won't be called
unless done so explicitly like:

class B(A):
def __init__(self):
print "in B.__init__()"
super(B, self).__init__( )

I'm sure there must be ample reason
for this. I would like to know why this is so? This is my view is more
burden on the programmer.

It isn't that much practical burden, and IMO it makes perfect sense.
When you override a method of a class, you want to have to explicitly
call superclass code, not have it run automatically, else you lose
control of the flow.

I'd like to reiterate this point. Say I have a class like:

class A(object):
def __init__(self, x):
self.x = x
print 'A.__init__'

and an inheriting class like:

class B(A):
def __init__(self, y):
...
print 'B.__init__'
...

If 'y' is the same thing as 'x', then I probably want to write B like:

class B(A):
def __init__(self, y):
super(B, self).__init__( y)
print 'B.__init__'

But what if 'x' has to be computed from 'y'? Then I don't want the
super call first. I probably want it last (or at least later), e.g.:

class B(A):
def __init__(self, y):
print 'B.__init__'
x = self._compute_x (y)
super(B, self).__init__( x)

If the superclass constructor is automatically called, how will it know
which meaning I want for 'y'? Is 'y' equivalent to 'x', or is it
something different? Since Python can't possibly know this for sure, it
refuses the temptation to guess, instead requiring the user to be explicit.

STeVe

[Sakesun Roykiattisak]

Does c++ call base class constructor automatically ??
If I'm not wrong, in c++ you also have to call base class constructor
explicitly.
Python just do not enforce the rule. You can leave it as desire.

BTW, I've once been an C++ expert. Knowing python kill that skill.
However, I'm not regret. I have c++ compiler installed, but I don't even
bother validate my last paragraph assertion. Too disgusting. ;)

Sriek wrote:

Tim pointed out rightly that i missed out the most crucial part of my
question.
i should have said that __init__() is not called automatically only for
the inheritance hierarchy. we must explicitly call all the base class
__init__() fuctions explicitly.
i wanted a reason for that.
Thanks Tim.

[Sriek]

if i understand C++ right, in c++ you CAN explicitly call the base
constructor ( for eg. if it requires some particular arguements ), but,
the compiler automatically has to call the base class constructor ( see
the rules for constructing an object of the derived classes ).

But, yes, C++ can be too disgusting sometimes. But, i like the C++
design philosophy ( read D & E of C++ ? ), the rasons for various
features are intellgently put inplace.

Correct me if i am wrong about both the paragraphs. ok? T
Thanks

[Sriek]

maybe like this:
we can have the default behaviour as calling the default constructor
( with default arguements where required ). Along with this, keep the
option open to call constructors explicitly.

My only contention is that there may be a greater reason for this rule
in the Python Language. thats it.

[Jeremy Sanders]

On Wed, 25 May 2005 21:31:57 -0700, Sriek wrote:

Similarly, why do we have to explicitly use the 'self' keyword everytime?

I didn't like that when starting Python. Now when I look back at C++ code,
I find it very hard to work out which variables and methods and members,
and which are not, unless the author used a clear naming convention.

Jeremy

[John Roth]

"Sriek" <sc*******@gmai l.com> wrote in message
news:11******** *************@z 14g2000cwz.goog legroups.com...

hi,
i come from a c++ background. i ws happy to find myself on quite
familiar grounds with Python. But, what surprised me was the fact that
the __init__(), which is said to be the equivlent of the constructor in
c++, is not automatically called. I'm sure there must be ample reason
for this. I would like to know why this is so? This is my view is more
burden on the programmer.
It depends on what you mean by a burden. If the init methods of
each subclass was always called, then you'd have to work out how
to make them cooperate in all cases. The way C++ works, it has to
call the constructors because the vtable has explicit sections for each
of the base classes, recursively to the (possibly multiple) bases of
the tree. In Python, that isn't true - you get one instance regardless
of the number of base classes or structure of the tree, and that
single instance contains all the identifiers needed. It's up to the
class you instantiate to decide how to build the instance.
Similarly, why do we have to explicitly use the 'self' keyword
everytime?
Python has no way of knowing, at compile time, whether an
identifier is an instance/class variable or a module/builtin.
Putting the instance among the parameters lets you treat it as
a local variable which the compiler is quite capable of handling.

Remember that you're dealing with a highly dynamic environment;
inspection of the single source module will not tell you enough to
make this distinction.

John Roth
Every kind of help would be welcome.