Inheritance and Inner/Nested Classes

Peter Hansen peter at
Mon Jul 12 19:08:50 CEST 2004

Paul Morrow wrote:

> Peter Hansen wrote:
>> 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.  

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

> 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

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. :-)


More information about the Python-list mailing list