A better way of making subsclassing of built-in types stick for attributes?

[telesphore4 at gmail.com]

Maric Michaud wrote:
> Le Mercredi 17 Mai 2006 06:17, telesphore4 at gmail.com a écrit :
> > I want the fact that the fields are
> > not strings to be invisible to the client programmers.
> You should use properties then.

I started with that idea, using the recipie 20.2 from the cookbook.
However,  this caused a fair amount of code bloat... Err the way I
implemented it did at least. I may be missing a way to regularize the
process and make the whole process cleaner too.

The problem was that I needed to set the properties for all of the
object fields with boilerplate code that looks very much the same. Even
if the boilerplate was small, it was still bigger than the one-line
descriptor definitions at the bottom of the module. Shrinking the
descriptor definitions to a one-liner shrunk the code by a fair bit.
There are many classes (100+ when I'm done) and some of them have a
fair number of fields (up to 50) and all of them have to have the
snazzyStr abilities.

Another problem was esthetics; it forces me to place the main class at
the bottom of the module after the definition of the supporting
classes. Putting the descriptors after the bottom of the module left
the important parts at the top where they should be, IMO.

I wanted to use supporting classes for the field definitions because it
allowed me to use mix-ins. This was the biggest win in the design.

Thanks
t4