> 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. Diez -- http://mail.python.org/mailman/listinfo/python-list
