Inheritance and Inner/Nested Classes

[Paul Morrow]

I'm hoping that someone can explain why I get the following exception.
When I execute the code...

######################################
class Parent(object):
class Foo(object):
baz = 'hello from Parent.Foo'

class Child(Parent):
#Foo.baz = 'hello from Child.Foo'
pass

print Child.Foo.baz
print dir(Child)
######################################

....it displays what I expect...

hello from Parent.Foo
['Foo', '__class__', '__delattr__', '__dict__', '__doc__',
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',
'__weakref__']

....but when I uncomment the first line of the Child class, Python
complains that Foo is undefined...

Traceback (most recent call last):
File "test1.py", line 5, in ?
class Child(Parent):
File "test1.py", line 6, in Child
Foo.baz = 'hello from Child.Foo'
NameError: name 'Foo' is not defined

Thanks in advance.

Paul

 

[Peter Hansen]

######################################
class Parent(object):
class Foo(object):
baz = 'hello from Parent.Foo'

class Child(Parent):
#Foo.baz = 'hello from Child.Foo'
pass

Here you want "Parent.Foo.bax = ..." instead.

What are you actually trying to do? This is unusual code,
I think...

-Peter

 

[Paul Morrow]

Here you want "Parent.Foo.bax = ..." instead.

What are you actually trying to do? This is unusual code,
I think...

-Peter

I'm trying to override the 'baz' class attribute in the Child.Foo
subclass, so that when I do...

x1 = Parent.Foo()
x2 = Child.Foo()

.... x1 and x2 have different internal states (different values for the
baz attribute). Without nested classes, the following code...

#####################################
class Parent(object):
baz = 'hello from Parent'

class Child(Parent):
baz = 'hello from Child'

print Parent.baz
print Child.baz
#####################################

....produces what I would expect...

hello from Parent
hello from Child

....but apparently my thinking is wrong on nested class definitions. It
seems odd that, according to dir(Child), Foo is inherited by Child, but
I can't refer to Foo in Child's class definition. And even if I
could, it wouldn't be a *copy* of the Parent's Foo that Child has, but
rather Parent's Foo itself --- changing Foo.baz in Child changes Foo.baz
in Parent, which is not what I want.

Thx.

 

[Peter Hansen]

I'm trying to override the 'baz' class attribute in the Child.Foo
subclass, so that when I do...

x1 = Parent.Foo()
x2 = Child.Foo()

... x1 and x2 have different internal states (different values for the
baz attribute).

Sorry, let me try the question in a different way. What end
goal, without reference to *how* you think you want to achieve it,
are you trying to achieve? You've posted what are obviously
contrived examples. I can't see the purpose here... other
than "different internal states", but if that's all it is
you don't need to have an inner class to do it (as you show
you know by the following

Without nested classes, the following code...

#####################################
class Parent(object):
baz = 'hello from Parent'

class Child(Parent):
baz = 'hello from Child'

print Parent.baz
print Child.baz
#####################################

...produces what I would expect...

hello from Parent
hello from Child

...but apparently my thinking is wrong on nested class definitions. It
seems odd that, according to dir(Child), Foo is inherited by Child, but
I can't refer to Foo in Child's class definition. And even if I could,
it wouldn't be a *copy* of the Parent's Foo that Child has, but rather
Parent's Foo itself --- changing Foo.baz in Child changes Foo.baz in
Parent, which is not what I want.

Exactly... so what *do* you want?

By the way, have you considered just using *instances* instead
of mucking directly in the classes themselves? That's the usual
way to go about object-oriented programming (and probably why it's
not called "class-oriented programming" . If you did that, you
would use the initializer __init__() to set up the different state
by creating an instance of the Foo class inside the Parent's
initializer, then making the appropriate changes inside the
Child's initializer after calling the Parent's...

Another question is why bother with the nested class? Why
not just stick Foo outside both classes? (Doing this would
first require doing what I suggested in the previous paragraph,
however...but it might show you why what you are doing now
is sort of weird and maybe pointless.)

-Peter

 

[Andrew Bennetts]

I'm trying to override the 'baz' class attribute in the Child.Foo
subclass, so that when I do...

x1 = Parent.Foo()
x2 = Child.Foo()

... x1 and x2 have different internal states (different values for the
baz attribute). Without nested classes, the following code...

I'm understanding what you want to do correctly, I guess you could do:

class Parent(object):
class Foo(object):
baz = 'hello from Parent.Foo'

class Child(Parent):
class Foo(Parent.Foo):
baz = 'hello from Child.Foo'

i.e. Parent.Foo is a class that just happens to be stored in as an attribute
of Parent, and so if you want to override it, you have to do so directly.
The fact that you're thinking of them as "nested" doesn't come into it,
except for referencing it.

-Andrew.

 

[Paul Morrow]

Sorry, let me try the question in a different way. What end
goal, without reference to *how* you think you want to achieve it,
are you trying to achieve? You've posted what are obviously
contrived examples. I can't see the purpose here... other
than "different internal states", but if that's all it is
you don't need to have an inner class to do it (as you show
you know by the following

Actually, it's the *how* that is my end goal <grin>.

I'm creating a framework that you parameterize by supplying objects that
contain particularly named attributes. The attributes tell the
framework what to do, when to do it, etc. So I'm trying to find a nice
and clean object structure that uses a minimum of syntax.

The framework parameters (in the object the developer supplies) fall
into a number of categories, so it seemed like a good idea to group
them, hence the inner classes idea. And yes, since we are talking about
objects, a more traditional object-oriented layout such as...

#####################################
class Parent(object):
class Foo(object):
def __init__(self):
self.baz = 'hello from Parent.Foo'

class Child(Parent):
class Foo(Parent.Foo):
def __init__(self):
self.baz = 'hello from Child.Foo'

x1 = Parent.Foo()
x2 = Child.Foo()
print x1.baz
print x2.baz
#####################################

....would work, but I was hoping to avoid having to create the
constructor methods as well as (re)declare the inner class in the
descendent/child classes. It looks like class attributes take care of
the former...

#####################################
class Parent(object):
class Foo(object):
baz = 'hello from Parent.Foo'

class Child(Parent):
class Foo(Parent.Foo):
baz = 'hello from Child.Foo'

x1 = Parent.Foo()
x2 = Child.Foo()
print x1.baz
print x2.baz
#####################################

.... but I don't see any way to avoid the later.

I know that this is still a contrived example, but just imagine that the
Foo inner class represents some customization category, and baz is a
customization variable in that category.

Thanks again.

 

[Peter Hansen]

I'm creating a framework that you parameterize by supplying objects that
contain particularly named attributes. The attributes tell the
framework what to do, when to do it, etc. So I'm trying to find a nice
and clean object structure that uses a minimum of syntax.

The framework parameters (in the object the developer supplies) fall
into a number of categories, so it seemed like a good idea to group
them, hence the inner classes idea. And yes, since we are talking about
objects, a more traditional object-oriented layout such as...

Thanks for the clarification. Based on what you are saying
here, I strongly suggest abandoning the idea of keeping
these attribute classes as inner classes. I think doing that
couples together two unrelated things and will cause much
more trouble in the long run than the modest reduction in
extra typing will save you.

The objects that are being parameterized (the ones the developer
supplies) are not the same thing as the parameterization objects.
The former are for the developer, and presumably have something
to do with the problem domain (whatever the framework is helping
the developer solve).

The parameterization objects, however, are *for* the framework,
not for the problem domain (if I'm understanding correctly)
and shouldn't be coupled with the other ones.

Even if they appear to be related (maybe because the types of
parameterization involved come directly from the problem
domain as well), I would still keep them very separate. Otherwise
you are mixing together the whole parameterization feature
with the rest of the system and the result will probably grow
unmanageable or at least complicated in due time.

-Peter

 

[Andrew Bennetts]

]

...would work, but I was hoping to avoid having to create the
constructor methods as well as (re)declare the inner class in the
descendent/child classes. It looks like class attributes take care of
the former...

#####################################
class Parent(object):
class Foo(object):
baz = 'hello from Parent.Foo'

class Child(Parent):
class Foo(Parent.Foo):
baz = 'hello from Child.Foo'

x1 = Parent.Foo()
x2 = Child.Foo()
print x1.baz
print x2.baz
#####################################

... but I don't see any way to avoid the later.

I know that this is still a contrived example, but just imagine that the
Foo inner class represents some customization category, and baz is a
customization variable in that category.

Well, the problem is that the way you say you want spell it is mutating a
shared object:

class Child(Parent):
Foo.baz = 'hello from Child.Foo'

If you want 'Foo' in Child to be a different object to the Foo in Parent,
then you need to somehow make it be a different object, which means
assigning to 'Foo' in Child's namespace. The simplest and clearest way to
do that is to explicitly subclass with "class Foo(Parent.Foo): ...".

-Andrew.

 

[Paul Morrow]

The objects that are being parameterized (the ones the developer
supplies) are not the same thing as the parameterization objects.

I'm not quite sure what you mean by "parameterization objects" as
opposed to what the developer creates. Note that there are two kinds of
developers here: one that works on the Framework; and one that builds
applications using the Framework. It's the later that I've been talking
about.

For each application, the application developer creates an object that
describes the application. This object contains a bunch of settings that
customize the Framework. For any given app, there are a lot of possible
settings, where the settings can be grouped into a number of categories
(security, style, structure, content, etc.). I could just say that the
namespace inside of the object (the app developer supplies) is flat, but
that would get messy fast. It seems that it would be better to store
related attributes together in their own namespace inside of the object.
That's what I imagined using the inner classes for.

 

[Paul Morrow]

Well, the problem is that the way you say you want spell it is mutating a
shared object:

class Child(Parent):
Foo.baz = 'hello from Child.Foo'

If you want 'Foo' in Child to be a different object to the Foo in Parent,
then you need to somehow make it be a different object, which means
assigning to 'Foo' in Child's namespace. The simplest and clearest way to
do that is to explicitly subclass with "class Foo(Parent.Foo): ...".

-Andrew.

Yes, I think that you may be right. But oh the tempation to look into
metaclasses for this...

Thanks.

 

[Peter Hansen]

I'm not quite sure what you mean by "parameterization objects" as
opposed to what the developer creates.

By that term, I meant the inner classes.

Note that there are two kinds of
developers here: one that works on the Framework; and one that builds
applications using the Framework. It's the later that I've been talking
about.

Understood. (I think. Without real examples I might be getting it
wrong.)

For each application, the application developer creates an object that
describes the application. This object contains a bunch of settings that
customize the Framework. For any given app, there are a lot of possible
settings, where the settings can be grouped into a number of categories
(security, style, structure, content, etc.). I could just say that the
namespace inside of the object (the app developer supplies) is flat, but
that would get messy fast. It seems that it would be better to store
related attributes together in their own namespace inside of the object.
That's what I imagined using the inner classes for.

I think I understand all of what you are saying. The only point I'm
making now is that it is neither necessary nor a good idea to use
inner classes for those things. They would, I believe, be better
handled as separately defined classes (probably in their own module(s))
which are instantiated inside the initializer method of the other
classes.

In fact, maybe the use of classes here is unnecessary too. Why not
just use a dictionary or dictionaries to store these various attributes?
Namespaces are in other areas of Python nothing more than dictionaries,
and it would seem that you could use dicts here in the same way,
with greater simplicity.

But without seeing the real thing, I suspect only you have enough
information to judge well. Go with whatever feels right.

-Peter