473,544 Members | 2,322 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

initializing mutable class attributes

There is something with initializing mutable class attributes that I am
struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong
because all the instances of Father end up sharing the same value. Maybe
that is desired sometimes, but usually it is just a bug.

So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]

This is already awkward because there is such a difference between attr1 and
attr2. But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]

I find this even more awkward because many people will forget to do it.
Clearly, this is then a more general issue with __init__, but I think it is
accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.

Is there something I don't know here and there is a better way to do this in
Python? I would like to get a better solution or otherwise start a
discussion.
Jul 18 '05 #1
50 6296
That's the way it is supposed to work. Instance attributes have to be
initialized via self.foo=..., usually in __init__() which in turn is
*STRONGLY* advised to class its parents __init__() - or you create
instance attributes 'on-the-fly' when they are used for the first time
(useful technique for mixin classes without constructor). Class
attributes are initialized once for the class and are shared between
instances.
"self.attr1=dat a" in Father.foo() doesn't "override" the Father.attr1
attribute you defined before. It creates an instance attribute that
shadows Father.attr1!
Both attribute assignments in Father are OK - if you treat them as class
attributes. They won't become instance attributes by hidden magic.

Dan Perl wrote:
There is something with initializing mutable class attributes that I am
struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong
because all the instances of Father end up sharing the same value. Maybe
that is desired sometimes, but usually it is just a bug.

So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]

This is already awkward because there is such a difference between attr1 and
attr2. But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]

I find this even more awkward because many people will forget to do it.
Clearly, this is then a more general issue with __init__, but I think it is
accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.

Is there something I don't know here and there is a better way to do this in
Python? I would like to get a better solution or otherwise start a
discussion.


Jul 18 '05 #2
Dan Perl <dp***@rogers.c om> wrote:
There is something with initializing mutable class attributes that I am
struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong
because all the instances of Father end up sharing the same value. Maybe
that is desired sometimes, but usually it is just a bug.
I disagree: good Python programmers often use mutable class attributes,
and use them to good effect. I've done my share of Python teaching,
consulting and mentoring, and I definitely do *not* think this usage "is
desired sometimes but usually it is just a bug".

So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]
This is the canonical way, sure.

This is already awkward because there is such a difference between attr1 and
attr2.
One is a class attribute (which nobody forced you to have), the other is
an instance attribute. If you want both to be instance attributes,
initialize both in __init__ -- that's all there is to it. Don't use
class attributes unless there's a reason for them to be class
attributes, that seems like a good and sensible rule of thumb to me.
But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]
Assuming an instance of Child needs to have both attributes attr2 and
attr3, yes.

I find this even more awkward because many people will forget to do it.
Forget to do what -- call the parent class's __init__? Again, this is
rare -- not as rare as the other "usually just a bug" you opined about,
but not common. A class normally needs __init__ for a large number of
purposes, of course, not just to assign mutable attributes to each
instance, therefore people who learn subclassing do learn to call the
parent class __init__ very early on, to avoid everything breaking.
Clearly, this is then a more general issue with __init__, but I think it is
accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.
Making __init__ more common means people are more likely to get used to
it, and thus makes the bug of not calling a parent class's __init__
rarer, not "accentuate d".

Is there something I don't know here and there is a better way to do this in
Python? I would like to get a better solution or otherwise start a
discussion.


There is no BETTER way, IMHO, than normal Python coding, which I believe
is quite good -- but you appear to disagree, therefore it's hard for me
to gauge what you may consider "better". There is definitely a
DIFFERENT way -- coding a custom metaclass which will tweak the
instantiation of all classes belonging to it, in order to insert some
funky initialization of mutable attributes, and perhaps automate calls
to superclasses' __init__ methods, and so on. Such automation is a
ticklish issue, in the general case, so let's assume initializing
mutable attributes is all we ever want to do. Then, for example...:

import copy
class metaImu(type):
def __call__(cls, *a, **k):
instance = type.__call__(c ls, *a, **k)
for sup in cls.mro():
muts = gerattr(sup, '__mutables__', ())
for mutname in muts:
if hasattr(instanc e, mutname): continue
mutvalue = muts[mutname]
setattr(instanc e, mutname, copy.copy(mutva lue))
return instance

class Father:
__metaclass__ = metaImu
__mutables__ = dict(attr1=None , attr2={})

class Child(Father):
__mutables__ = dict(attr3=[])

I haven't tested this, but I believe it should behave as you appear to
desire (assuming you want shallow rather than deep copying of the
values, of course: I can't read your mind!). I specifically showed that
you can use __mutables__ also for attributes which are in fact not
mutable, since copy.copy should be innocuous (identity) on those, just
in case you insist on having the same form for all such attributes. I
have also assumed that an instance's __init__ may be allowed to set its
own value for an attribute in __mutables__ and if it does so then that
should be left alone. But of course you can play with all of these
aspects at will. You could even have that __call__ method examine all
attributes defined in the class (or any superclass) and force copies of
them into instance attributes for all whose types are [[whatever
criteria you like...]].
Alex
Jul 18 '05 #3
I will clarify something that was probably not clear enough in my initial
posting. I am interested in instance attributes, but I am using the class
attributes to provide a default, "null", value for the instance attributes.
Yes, the instance attributes only mask the class ones, but a class attribute
and an instance attribute can be used like this:
class WorksForMe:
attr=None # used just as a default value for the instance
attribute self.attr
def foo(self):
self.attr=Somet hingUseful( )
def bar(self):
if self.attr:
useIt(self.attr )
else:
ignoreIt(self.a ttr)
This makes it safe for an instance of WorksForMe to invoke bar( ) even if it
never invoked foo( ).

"Benjamin Niemann" <b.*******@bett ernet.de> wrote in message
news:cg******** **@online.de...
That's the way it is supposed to work. Instance attributes have to be
initialized via self.foo=..., usually in __init__() which in turn is
*STRONGLY* advised to class its parents __init__() - or you create
instance attributes 'on-the-fly' when they are used for the first time
(useful technique for mixin classes without constructor). Class
attributes are initialized once for the class and are shared between
instances.
You are confirming the code I suggested but you don't share my view that
such code is awkward. I think I I was actually conservative calling it
awkward, I would rather call it unsafe. If I were a third-party library
vendor, I would not be comfortable providing a mixin class that forces users
to either invoke the parent's __init__ in their constructors or to
initialize the instance attributes on-the-fly. The latter would even be
against the principles of encapsulation, users should not need to know about
the parent's attributes, especially because they may change in future
releases. Both ways of restricting the use of the mixin class are unsafe
because they are easy to be ignored by users. And it is not only the users'
fault if they do not follow the restrictions, it is also my fault to put
such restrictions in the first place.

I think this points to a weakness in Python as an OO language. I'm not
trying to bash it, but my understanding is that Python is still evolving in
that respect and I think that this should be improved in the future. Then,
on the other hand, maybe I'm the only one feeling this way and there's not
going to be a change.
"self.attr1=dat a" in Father.foo() doesn't "override" the Father.attr1
attribute you defined before. It creates an instance attribute that
shadows Father.attr1!
Both attribute assignments in Father are OK - if you treat them as class
attributes. They won't become instance attributes by hidden magic.

Dan Perl wrote:
There is something with initializing mutable class attributes that I am
struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong
because all the instances of Father end up sharing the same value. Maybe that is desired sometimes, but usually it is just a bug.

So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]

This is already awkward because there is such a difference between attr1 and attr2. But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]

I find this even more awkward because many people will forget to do it.
Clearly, this is then a more general issue with __init__, but I think it is accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.

Is there something I don't know here and there is a better way to do this in Python? I would like to get a better solution or otherwise start a
discussion.

Jul 18 '05 #4
Dan Perl wrote:
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]

I find this even more awkward because many people will forget to do it.


You have to call base-class-__init__() in every non-trivial inheritance
scheme. Should you forget it, pychecker is always there to remind you

<sloppy-code>
class X:
def __init__(self):
self.x = 2

class Y(X):
pass

class Z(Y):
def __init__(self):
pass
</sloppy-code>

And here's what pychecker says:

$ pychecker t1.py
Processing t1...

Warnings...

t1.py:9: Base class (t1.Y) __init__() not called

Clear enough.

Peter

Jul 18 '05 #5
Dan,

I too use class attributes to assign defaults, but do
it like following:

import copy

class Father:
_attr1default=N one
_attr2default=[]

def __init__(self):
self.attr1=self ._attr1default
# Get copy of attr2default
self.attr2=list (self._attr2def ault)

def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
class Child (Father):
def __init__(self):
Father.__init__ (self)
#
# At this point self.attr1 (instance)
# and self.attr2 (instance) hold their defaults
# while _attr1/_attr2default (class) still hold
# their default values for initialization of more
# class instances.
#

HTH,
Larry Bates
Syscon, Inc.
"Dan Perl" <dp***@rogers.c om> wrote in message
news:sH******** ***********@new s01.bloor.is.ne t.cable.rogers. com...
I will clarify something that was probably not clear enough in my initial
posting. I am interested in instance attributes, but I am using the class
attributes to provide a default, "null", value for the instance attributes. Yes, the instance attributes only mask the class ones, but a class attribute and an instance attribute can be used like this:
class WorksForMe:
attr=None # used just as a default value for the instance
attribute self.attr
def foo(self):
self.attr=Somet hingUseful( )
def bar(self):
if self.attr:
useIt(self.attr )
else:
ignoreIt(self.a ttr)
This makes it safe for an instance of WorksForMe to invoke bar( ) even if it never invoked foo( ).

"Benjamin Niemann" <b.*******@bett ernet.de> wrote in message
news:cg******** **@online.de...
That's the way it is supposed to work. Instance attributes have to be
initialized via self.foo=..., usually in __init__() which in turn is
*STRONGLY* advised to class its parents __init__() - or you create
instance attributes 'on-the-fly' when they are used for the first time
(useful technique for mixin classes without constructor). Class
attributes are initialized once for the class and are shared between
instances.
You are confirming the code I suggested but you don't share my view that
such code is awkward. I think I I was actually conservative calling it
awkward, I would rather call it unsafe. If I were a third-party library
vendor, I would not be comfortable providing a mixin class that forces

users to either invoke the parent's __init__ in their constructors or to
initialize the instance attributes on-the-fly. The latter would even be
against the principles of encapsulation, users should not need to know about the parent's attributes, especially because they may change in future
releases. Both ways of restricting the use of the mixin class are unsafe
because they are easy to be ignored by users. And it is not only the users' fault if they do not follow the restrictions, it is also my fault to put
such restrictions in the first place.

I think this points to a weakness in Python as an OO language. I'm not
trying to bash it, but my understanding is that Python is still evolving in that respect and I think that this should be improved in the future. Then, on the other hand, maybe I'm the only one feeling this way and there's not
going to be a change.
"self.attr1=dat a" in Father.foo() doesn't "override" the Father.attr1
attribute you defined before. It creates an instance attribute that
shadows Father.attr1!
Both attribute assignments in Father are OK - if you treat them as class
attributes. They won't become instance attributes by hidden magic.

Dan Perl wrote:
There is something with initializing mutable class attributes that I am struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong because all the instances of Father end up sharing the same value. Maybe that is desired sometimes, but usually it is just a bug.

So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]

This is already awkward because there is such a difference between attr1
and
attr2. But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]

I find this even more awkward because many people will forget to do
it. Clearly, this is then a more general issue with __init__, but I think
it is accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.

Is there something I don't know here and there is a better way to do this in Python? I would like to get a better solution or otherwise start a
discussion.


Jul 18 '05 #6

"Alex Martelli" <al*****@yahoo. com> wrote in message
news:1gjc8cs.sq vo1v1fhabdjN%al *****@yahoo.com ...
Dan Perl <dp***@rogers.c om> wrote:
There is something with initializing mutable class attributes that I am
struggling with. I'll use an example to explain:
class Father:
attr1=None # this is OK
attr2=[ ] # this is wrong
def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
The initialization of attr1 is obviously OK, all instances of Father
redefine it in the method foo. But the initialization of attr2 is wrong
because all the instances of Father end up sharing the same value. Maybe that is desired sometimes, but usually it is just a bug.


I disagree: good Python programmers often use mutable class attributes,
and use them to good effect. I've done my share of Python teaching,
consulting and mentoring, and I definitely do *not* think this usage "is
desired sometimes but usually it is just a bug".


My mistake. I shouldn't have made that statement. I don't really know
which case happens more often. Having said that, that is probably a mistake
that many beginners make. Okay, I have no real way of knowing that either,
but I think it's a good assumption.
So the only solution I see to this is to initialize attr2 in __init__:
class Father:
attr1=None
def __init__(self):
self.attr2=[ ]


This is the canonical way, sure.

This is already awkward because there is such a difference between attr1 and attr2.


One is a class attribute (which nobody forced you to have), the other is
an instance attribute. If you want both to be instance attributes,
initialize both in __init__ -- that's all there is to it. Don't use
class attributes unless there's a reason for them to be class
attributes, that seems like a good and sensible rule of thumb to me.


I was using the class attribute as a default, "null", value for the instance
attributes. That works just fine for immutable attributes and it allows me
not to implement an __init__.
But moreover, I think this forces subclasses of Father to do
something like this:
class Child (Father):
def __init__(self):
Father.__init__ (self)
self.attr3=[ ]


Assuming an instance of Child needs to have both attributes attr2 and
attr3, yes.

I find this even more awkward because many people will forget to do it.


Forget to do what -- call the parent class's __init__? Again, this is
rare -- not as rare as the other "usually just a bug" you opined about,
but not common. A class normally needs __init__ for a large number of
purposes, of course, not just to assign mutable attributes to each
instance, therefore people who learn subclassing do learn to call the
parent class __init__ very early on, to avoid everything breaking.
Clearly, this is then a more general issue with __init__, but I think it is accentuated by the fact that you HAVE TO HAVE __init__ in order to
initialize attributes that are mutable.


Making __init__ more common means people are more likely to get used to
it, and thus makes the bug of not calling a parent class's __init__
rarer, not "accentuate d".


I'm leaving the rest of your reply out, but thanks for the suggestion of a
metaclass, I'll look into it.

After seeing a few replies (yours, Benjamin Niemann's and Peter Otten's) to
my initial posting, I think I am getting the picture that there is a
conscious decision to keep the use of __init__ the way it is and just make
people learn it and learn it early enough. That's a valid approach and I'll
accept it.

I can also understand your frustration with people who are new to Python,
like me, coming from a background in other OO languages, who are not yet
comfortable with "the Python way" and feel that there is a "better way" and
who suggest changing Python. But you also have to be reallistic and accept
that there will always be people coming to Python from other languages and
that the adjustment is rather difficult in some areas. You may just say
'Tough!', or you may help them to make that adjustment (I think you are
doing that), or you may even accommodate them (you should at least consider
that).

No one, including you, has given me a reason WHY __init__ is implemented
this way. I am not bashing you for that, I would just still like to hear
that 'WHY'. I'm sure that this implementation has some advantages. But,
coming from a C++ and Java background, where parent default constructors are
automatically invoked (well, not always, and that is something that users
have to learn too), I find that that approach has some clear advantages.

Those are my 2 cents.

Dan
PS: Does my last name attract the wrong kind of attention from people in
this newsgroup? It's really my name, it's not fake, BTW.
Jul 18 '05 #7
Larry,

I don't think it is very different from what I suggested. You still
implement an __init__ and you initialize the instance attributes there.

Thanks, though. It's a nice trick and it's useful because you have a
default value that can be used also in other places in the code (like
restoring the default). And it's probably a good use of pseudo-private
class attributes.

Dan

"Larry Bates" <lb****@swamiso ft.com> wrote in message
news:29******** ************@co mcast.com...
Dan,

I too use class attributes to assign defaults, but do
it like following:

import copy

class Father:
_attr1default=N one
_attr2default=[]

def __init__(self):
self.attr1=self ._attr1default
# Get copy of attr2default
self.attr2=list (self._attr2def ault)

def foo(self, data):
self.attr1=data
self.attr2.appe nd(data)
class Child (Father):
def __init__(self):
Father.__init__ (self)
#
# At this point self.attr1 (instance)
# and self.attr2 (instance) hold their defaults
# while _attr1/_attr2default (class) still hold
# their default values for initialization of more
# class instances.
#

HTH,
Larry Bates
Syscon, Inc.
"Dan Perl" <dp***@rogers.c om> wrote in message
news:sH******** ***********@new s01.bloor.is.ne t.cable.rogers. com...
I will clarify something that was probably not clear enough in my initial
posting. I am interested in instance attributes, but I am using the class attributes to provide a default, "null", value for the instance attributes.
Yes, the instance attributes only mask the class ones, but a class

attribute
and an instance attribute can be used like this:
class WorksForMe:
attr=None # used just as a default value for the instance
attribute self.attr
def foo(self):
self.attr=Somet hingUseful( )
def bar(self):
if self.attr:
useIt(self.attr )
else:
ignoreIt(self.a ttr)
This makes it safe for an instance of WorksForMe to invoke bar( ) even if it
never invoked foo( ).

"Benjamin Niemann" <b.*******@bett ernet.de> wrote in message
news:cg******** **@online.de...
That's the way it is supposed to work. Instance attributes have to be
initialized via self.foo=..., usually in __init__() which in turn is
*STRONGLY* advised to class its parents __init__() - or you create
instance attributes 'on-the-fly' when they are used for the first time
(useful technique for mixin classes without constructor). Class
attributes are initialized once for the class and are shared between
instances.
You are confirming the code I suggested but you don't share my view that
such code is awkward. I think I I was actually conservative calling it
awkward, I would rather call it unsafe. If I were a third-party library
vendor, I would not be comfortable providing a mixin class that forces

users
to either invoke the parent's __init__ in their constructors or to
initialize the instance attributes on-the-fly. The latter would even be
against the principles of encapsulation, users should not need to know

about
the parent's attributes, especially because they may change in future
releases. Both ways of restricting the use of the mixin class are

unsafe because they are easy to be ignored by users. And it is not only the

users'
fault if they do not follow the restrictions, it is also my fault to put
such restrictions in the first place.

I think this points to a weakness in Python as an OO language. I'm not
trying to bash it, but my understanding is that Python is still evolving

in
that respect and I think that this should be improved in the future.

Then,
on the other hand, maybe I'm the only one feeling this way and there's not going to be a change.
"self.attr1=dat a" in Father.foo() doesn't "override" the Father.attr1
attribute you defined before. It creates an instance attribute that
shadows Father.attr1!
Both attribute assignments in Father are OK - if you treat them as class attributes. They won't become instance attributes by hidden magic.

Dan Perl wrote:
> There is something with initializing mutable class attributes that I

am > struggling with. I'll use an example to explain:
> class Father:
> attr1=None # this is OK
> attr2=[ ] # this is wrong
> def foo(self, data):
> self.attr1=data
> self.attr2.appe nd(data)
> The initialization of attr1 is obviously OK, all instances of Father
> redefine it in the method foo. But the initialization of attr2 is wrong > because all the instances of Father end up sharing the same value.

Maybe
> that is desired sometimes, but usually it is just a bug.
>
> So the only solution I see to this is to initialize attr2 in __init__: > class Father:
> attr1=None
> def __init__(self):
> self.attr2=[ ]
>
> This is already awkward because there is such a difference between attr1
and
> attr2. But moreover, I think this forces subclasses of Father to do
> something like this:
> class Child (Father):
> def __init__(self):
> Father.__init__ (self)
> self.attr3=[ ]
>
> I find this even more awkward because many people will forget to do

it. > Clearly, this is then a more general issue with __init__, but I

think it
is
> accentuated by the fact that you HAVE TO HAVE __init__ in order to
> initialize attributes that are mutable.
>
> Is there something I don't know here and there is a better way to do

this in
> Python? I would like to get a better solution or otherwise start a
> discussion.



Jul 18 '05 #8
On Mon, 30 Aug 2004 15:39:54 GMT, Dan Perl <dp***@rogers.c om> wrote:

"Alex Martelli" <al*****@yahoo. com> wrote in message
news:1gjc8cs.sq vo1v1fhabdjN%al *****@yahoo.com ...
> So the only solution I see to this is to initialize attr2 in __init__:
> class Father:
> attr1=None
> def __init__(self):
> self.attr2=[ ]
This is the canonical way, sure.

Snip
After seeing a few replies (yours, Benjamin Niemann's and Peter Otten's) to
my initial posting, I think I am getting the picture that there is a
conscious decision to keep the use of __init__ the way it is and just make
people learn it and learn it early enough. That's a valid approach and I'll
accept it.
Snip
No one, including you, has given me a reason WHY __init__ is implemented
this way. I am not bashing you for that, I would just still like to hear
that 'WHY'. I'm sure that this implementation has some advantages. But, Explicit is better than implicit

import this

Dan
PS: Does my last name attract the wrong kind of attention from people in
this newsgroup? It's really my name, it's not fake, BTW.

My nick littlejohn is the direct translation of my last name and I'm
far from big. So what ? :=)
Jul 18 '05 #9
Thanks, Peter. pychecker detecting the wrong use makes the argument that
there is no excuse for making the mistake of not calling the parent's
__init__ in subclasses. I am regularly using pychecker on my code, but I
never saw that warning because I did use __init__ correctly.

But I did make the mistake once of using a class attribute with an empty
dictionary to initialize an instance attribute just because I was doing the
same thing with immutable attributes. Fortunately, I caught it soon enough
and I will not make that mistake again. But it was kind of an embarrassing
mistake and I learned my lesson only after that.

Dan

"Peter Otten" <__*******@web. de> wrote in message
news:cg******** *****@news.t-online.com...
You have to call base-class-__init__() in every non-trivial inheritance
scheme. Should you forget it, pychecker is always there to remind you
[....]
And here's what pychecker says:

$ pychecker t1.py
Processing t1...

Warnings...

t1.py:9: Base class (t1.Y) __init__() not called

Clear enough.

Peter

Jul 18 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.