Re-executing the code object from a class 'declaration'

Carlos Ribeiro carribeiro at
Wed Oct 6 19:28:25 CEST 2004

On Wed, 6 Oct 2004 18:58:40 +0200, Alex Martelli <aleaxit at> wrote:
> Carlos Ribeiro <carribeiro at> wrote:
> > def BuildTemplate(<template parameters>)
> >     class TemplateClass(...):
> >         ...
> >     return TemplateClass
> >
> > It's simple, and less hackish, but still unusual. I fear I may be
> > missing something on my design, if I need to resort to such hacks.
> Personally, I _like_ using 'class' statements to make classes and 'def'
> statements to make functions; I don't see either as hacks.  Messing with
> bytecodes, building a function with new.function around a certain code
> object, calling the metaclass explicitly... that feels more hackish to
> me, personally.  I do it when I must, but 99.9% of the time I have no
> problem avoiding it in production code, it seems to me.

I'm not sure if I understood what you meant. My common sense tells me
that the class-inside-a-def is more acceptable, given all the black
magic that we had to go through to be able to re-execute the class
statement. But the function above really returns a class... which is
'wrong', but many counts (although nothing stops it from happening,
after all, classes are objects pretty much like any other object,
albeit with the special ability to build new objects instances).

On the other hand, the re-execute-class-statement trick is a real hack
-- specially when seen from the inside. However, if everything is
clearly hidden in a metaclass (and I mean, a *real* metaclass, not a
def __metaclass__()); better yet, if the metaclass itself is hidden in
a base class; what do you think is cleaner?

a) class-inside-a-def

def BuildTemplate(<template parameters>)
    class TemplateClass(...):
    return TemplateClass
T = BuildTemplate(<params>)

b) re-exec-class

# GenericTemplate is a metaclass-enabled ancestor
from template import GenericTemplate
class TemplateClass(GenericTemplate):

T = TemplateClass.NewTemplate(<params>)

c) neither of the above -- there must be a better way to do it.

Carlos Ribeiro
Consultoria em Projetos
mail: carribeiro at
mail: carribeiro at

More information about the Python-list mailing list