Question: Inheritance from a buil-in type

D

Duncan Booth

T. Kaufmann said:
A simple but important question:

How can I initialize a super class (like dict) correctly in my
subclass constructor?

A sample:

class MyClass(dict):
def __init__(self):
dict.__init__(self)
...


Is there a general rule to do this for all buil-in types?

There are two rules. Generally, immutable objects get their initial values
from the constructor (__new__) while mutable objects are constructed with a
default value (e.g. empty list or dict) and are then set by the initialiser
(__init__) method. A few types which you might expect to be immutable are
actually mutable (e.g. property).

Mutable example (use for list, dict, property, etc.):

class MyClass(dict):
def __init__(self, *args, **kw):
dict.__init__(self, *args, **kw)

Immutable example (use for tuple, int, etc.):

class MyClass(tuple):
def __new__(cls, *args, **kw):
return tuple.__new__(cls, *args, **kw)

If there is any chance of your class being subclassed with multiple
inheritance involved, you should consider using super instead of naming the
baseclass directly, but most of the time you can get away with a direct
call to the baseclass.
 
T

T. Kaufmann

Hi there,

A simple but important question:

How can I initialize a super class (like dict) correctly in my subclass constructor?

A sample:

class MyClass(dict):
def __init__(self):
dict.__init__(self)
...


Is there a general rule to do this for all buil-in types?

Thanks for help.

Thomas
 
A

Alex Martelli

T. Kaufmann said:
Hi there,

A simple but important question:

How can I initialize a super class (like dict) correctly in my subclass
constructor?

Generally, you also want to override __new__ -- not in all cases can
you do all you want in __init__ by itself (e.g., it's far too late
when you inherit from immutable types, such as numbers, str, tuple).

A sample:

class MyClass(dict):
def __init__(self):
dict.__init__(self)
...

Yeah, you can do this, but the dict.__init__ call with just the
self parameter is actually redundant (it wouldn't be if there
WERE arguments -- either keyword ones, or a sequence of pairs,
or both -- with which to actually initialize a non-empty dict...).

Is there a general rule to do this for all buil-in types?

Generally, the super built-in may be advisable if you think you
may ever be involved in a multiple-inheritance graph. But that
is no different whether built-in types are involved, or not. I'm
not sure what "general rule" may be different for built-in types
than for others -- offhand, I don't think there are such differences.


Alex
 
A

Asun Friere

Duncan Booth said:
There are two rules. Generally, immutable objects get their initial values
from the constructor (__new__) while mutable objects are constructed with a
default value (e.g. empty list or dict) and are then set by the initialiser
(__init__) method. A few types which you might expect to be immutable are
actually mutable (e.g. property).

What is the thinking behind that? I mean you /can/ pass initial values
to a mutable using __new__, eg

class MyList (list) :
def __new__(cls, *args, **kwargs) :
return list.__new__(cls, *args, **kwargs)

or __init__ to pass values to a newly created immutable, eg

class MyTuple (tuple) :
def __init__(self, *args, **kwargs) :
return super(tuple, self).__init__(*args, **kwargs)

can't you? What's the pitfall?
 
D

Duncan Booth

(e-mail address removed) (Asun Friere) wrote in

What is the thinking behind that? I mean you /can/ pass initial values
to a mutable using __new__, eg

class MyList (list) :
def __new__(cls, *args, **kwargs) :
return list.__new__(cls, *args, **kwargs)

or __init__ to pass values to a newly created immutable, eg

class MyTuple (tuple) :
def __init__(self, *args, **kwargs) :
return super(tuple, self).__init__(*args, **kwargs)

can't you? What's the pitfall?
The pitfall is that these aren't doing what you think. In both cases you
just passed the original arguments straight through, so the list also got
the arguments it expected in its __init__ method, and the tuple got its
expected arguments in __new__. If you modify the arguments in any way
you'll find that your code still only sees the original arguments.

list.__init__ and tuple.__new__ act on their arguments.
list.__new__ and tuple.__init__ ignore their arguments.

Take the tuple example. tuple() takes 0 or 1 arguments, so you can't write:

tuple(1, 2, 3)

So define a class to do this:
def __new__(cls, *args):
return tuple.__new__(cls, args)

(1, 2, 3)

Now try this with __init__ and the default __new__ will complain:
def __init__(self, *args):
tuple.__init__(self, args)

Traceback (most recent call last):
File "<pyshell#73>", line 1, in ?
MyTuple(1, 2, 3)
TypeError: tuple() takes at most 1 argument (3 given)


If you try subclassing list, then this example shows clearly that the
arguments to __new__ are actually ignored:
def __new__(cls, *args, **kwargs) :
return list.__new__(cls, *args, **kwargs)
def __init__(self, *args, **kwargs):
print "list before init",self
list.__init__(self, *args, **kwargs)

list before init []
[1, 2, 3]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,266
Messages
2,571,342
Members
48,018
Latest member
DelilahDen

Latest Threads

Top