[Baypiggies] puzzle: binding invocation context for a function call during a class declaration

Bill Janssen janssen at parc.com
Wed Jan 5 00:48:39 CET 2011

Zachary Collins <recursive.cookie.jar at gmail.com> wrote:

> In general I think it is not possible without some other explitic
> mechanism to determine the class calling context, because it doesn't
> fit nicely into the overall system and doesn't have many valid uses.
> Besides, you're asking Python to hand you a reference to a class
> before it is made, even when it /might not be made/.

This is one of these load/compile/eval questions, I guess.

Just during the definition of the class, *something* has to be made.
There must be a new local context that's created by the "class"
statement, into which new variable assignments are put.  Now, what
eventually happens to those is determined by a larger context, indeed.

But what I think I'd like to have is a better way of adding information
to the set of stuff the metaclass has when it decides what to do with
__new__().  A way to scribble on the class declaration context in a
structured way.

>  Remember that
> because of meta classes and decorators and execution order, you can
> perfectly execute an entire class and not end up instantiating any
> class at all!  Better to solve the problem also in a way that is not
> syntatically confusing to a normal python user.  How is it obviously
> that invoking a function inside a class definition has side effects to
> that class?  Isn't that what meta classes, decorators, and assignment
> operators are supposed to be in the first place?
> I know it sounds combative, but what I'm getting at is: I think that
> in your pursuit of copying another language's syntax, you're avoiding
> better python solutions.

Sure, I hear you.  But while that's a fine way to go, I'm interested in
seeing what parts of Python could be beefed up in order to better use it
as a foundation for declarative languages.


More information about the Baypiggies mailing list