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

[Carlos Ribeiro]

On Wed, 6 Oct 2004 21:18:40 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
> ... no big deal,
> not comparable to (e.g.) building up a string and then doing 'exec' on
> it (THAT _is_ sinful and bad and maybe will make Guido cry...;-).

I swear I'll not go down to this level ;-)
 
> To be honest I never really understood why you liked that one so much,
> apart from the fascinating possibilities it offers for delving into
> normally ignored details of 'class' statements' execution;-)

That was part of the fun ;-)
 
> Seriously: classes have one incredible syntax advantage when you expose
> them to users... users who write class statements get to write any gd
> code they like in a context where every localname created ends up in a
> dict, then your metaclass gets to process the dict, etc, etc.  In
> comparison, functions are fine, with keyword parameters, for the
> equivalent of assignment statements, i.e.,
> 
> class foo(subletWayToGetMetaclassOmega):
>     bar = 23
> 
> and
> 
> foo = factoryFunctionOmega(bar=23)
> 
> are roughly equivalent; but as soon as the body of 'class foo' starts
> having def statements, class statements, loops, etc, the factory
> function has a hard time keeping up.  This syntax advantage has little
> to do with the *intended* semantics of 'class' vs function calls, and is
> the root of most "metaclass abuse" I've seen (and perpetrated -- though
> not in production code...).

Well, I'm looking into it for a couple of reasons. One of them is
exactly this -- code inside a class is much easier to write and to
structure than similar code inside a def... specialy when it comes to
data declarations[1]. A def is pretty much limited to one level; with
classes, it's easy to 'nest' groups of data declarations, which make
it easier to build complex hierarchical stuff. The other reason is to
be able to build something related to C++ templates -- a factory that
produces customized versions of a class based on parameters, that may
include other classes. I *thought* that a purely class-based
templating would make it easier to understand and manage, specially if
the magic is done "behind the scenes". But I'm not so sure now.

[1] I think that this is the correct term, in this context... but I
may be wrong (again).

> But it doesn't seem to be what you're after, and a couple days ago I saw
> somebody else asking about a metaclass to be called directly (where a
> class statement _was_ clearly what they needed, IMHO), so there must be
> something more going on here... I think I'll nickname it "class
> struggle"... many people DO seem to be struggling with classes, these
> days...
> 
> 
> > c) neither of the above -- there must be a better way to do it.
> 
> ...must there...?  Maybe I'm being short-sighted (wouldn't be the first
> time), but I can't see.  If you could have your heart's desire, within
> the general framework of Python, how WOULD you code what you're after
> (which I'm still not entirely clear about)?  I mean, how would it look
> to the user -- how it looks like _inside_ is a relatively minor issue...
 
Well, I don't think that (c) applies. But I was afraid that other
people, coming with a fresh mental picture of the problem, could point
to other types of solution. That's what (c) really means.
 
> 
> Alex
> --
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com