Removing inheritance (decorator pattern ?)

Diez B. Roggisch deets at
Mon Jun 16 18:20:31 CEST 2008

> Ok, I see how this would work (and it's trivial to make it cache the
> generated classes for future use) but I guess I was looking for a more
> "mainstream" approach, something that even a primitive statically
> typed language could run :) Even in Python though, I think of Runtime
> Type Generation like eval(); it's good that it exists but it should be
> used as a last resort. Also RTG doesn't play well with pickling.
> Since I don't have many useful subclasses so far, I'll stick with
> explicit inheritance for now but I'll consider RTG if the number of
> combinations becomes a real issue.

I wouldn't compare the usage of the type-constructor to "eval". Python *is*
a dynamic language, and it explicitly exposes parts of it's internals
through things like metaclasses, descriptors and such.

And your requirements simply can't be met by a "traditional" language. There
it's either decoration or similar approaches, or nothing - especially you
can't create objects that will survive static type-analysis with aggregated
subclasses. You must lose that information through the delegation-nature of
these recipes.


More information about the Python-list mailing list