AST decoration vs byte-code-munging (Was: Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code))

[Bengt Richter]

On Sun, 10 Jul 2005 16:26:24 -0400, "Terry Reedy" <tjreedy at udel.edu> wrote:

>
>"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message 
>news:20050710133959.83611.qmail at web31512.mail.mud.yahoo.com...
>
>I have a suggestion I don't remember seeing for flagging which vars to 
>autoinit without new syntax: use '_' instead of '.'.  I have never seen 
>local vars with a leading '_'.  So, in combination with whatever other 
>mechanism (metaclass, __init__ decorator?)
>
>   def __init__(self, _x, y, _z) :
>
>would automatically do self.x = _x, self.z = _z, but not self.y = y.
>
Of course, if it works for __init__, it should work for an arbitrary
method or even function (if a decorator is used).

I think I could write a byte-code-modifying decorator that would insert
code at the beginning of a function to do the
    self.x = _x; self.z = _z # but not self.y = y
in your example, and similarly for others.
But I am not sure it's not a waste of time to do these byte-code things
except to see how using such decorators feels in practice, or whether any
byte-code munging after generation is a good idea.

What would be the next step? To implement the same in C as a built in decorator?
I'm wondering if the effort of munging byte code isn't misplaced, and would create
a growing maintenance problem as more built-in decorators like that accumulated.

So, if we want alternate code generated, perhaps we need a way of talking to the
original code generation process? I'm thinking some kind of source-processing-time
decorator (maybe marked with double-@, like
    @@auto_init_self_attributes
    def __init__(self, _x, y, _z) : print 'self.y=%r not set'%y

The idea is for @@deco to be intercepted as part of the AST of the unit being compiled,
and be converted at that time to call with the AST and its own location in the tree being
passed to it so it can do mods to the AST  (and cut itself out), and then let the resulting
AST be compiled as normal. Multiple @@decorators would each get their chance to mod the AST
before compilation. This still would have some version dependency, but it wouldn't be
byte code hacking ;-) One of these days I'll think some more on @@. As an experiment, I think
the tokenizer could translate @@deco to _AT_AT_deco and let the AST be formed with that
apparent function call at that place in the code. Then the AST could be walked to find the _AT_AT_<deconame>
calls and extract them and compile them and execute them (the _AT_AT_deco functions would
obviously have to be defined already, so they might be looked up in some standard place
like trying to do place = __import__(_AT_AT_MODULE_) wher _AT_AT_MODULE_ gets defined sort
of like __METACLASS__.), passing the AST and the _AT_AT_deco call location therein, and the rest
of the parameters.

AST decoration would introduce macro-like capabilities, but restricted to transforming valid ASTs,
so it isn't like source text rewriting macros.

Sorry for the run-on stream of consciousness ;-/

Regards,
Bengt Richter