[Compiler-sig] Ugly hacks: modifying instance_getattr

[Greg Stein]

Take a look at using Python's "metaclasses" feature:

    http://www.python.org/doc/essays/metaclasses/

While there is a lot there to get your head around, take a look at some of
the examples. That could give you a quick peek into whether/how to do your
"hook into a method call" gimmick.

And you don't even have to modify the interpreter :-)

Cheers,
-g

On Mon, Nov 27, 2000 at 03:05:51AM -0500, Tripp Lilley wrote:
> This isn't exactly a compilation issue, but it's somewhat related, and I
> didn't see an obvious "ugly hacks" or "interpreter devloper" list
> mentioned anywhere out front.
> 
> I have modified my interpreter so that, in the LOAD_ATTR case statement,
> it peeks ahead in the code and looks to see if the next opcode is
> "CALL_FUNCTION". If so, I'd like to use slightly different getattr steps
> to resolve the attribute reference.
> 
> For resolution of the call o.XXX( ), I'd like my getattr to use these
> steps:
> 
> 	- if an attribute called __meth_XXX__ exists, return it.
> 	- if an attribute called __getmethod__ exists, call it to allow
> 	  it to resolve the attribute. If it returns "None", continue
> 	  looking for the attribute.
> 	- continue with "normal" attribute resolution semantics
> 
> Basically, the idea is to be able to trap attribute accesses that are
> going to be immediately used as method invocations. Why?
> 
> 	http://sourceforge.net/projects/selfish/
> 
> But that's another story. At this point, I can, more or less, determine
> the right "context" in which I want to apply these semantics. With the
> hack to eval_code2, I trap bytecode method invocations, and with a
> modification to PyObject_CallMethod, I trap C API method invocations.
> What I now need to do is pass that contextual "hint" down into the
> various flavours of getattr.
> 
> What's the most "friendly" way of approaching that? Since I can't use
> default arguments, adding another parameter to getattrofunc would mean
> I'd have to modify all of the modules to pass the parameter. Yuck. I
> can't use a global variable because of thread safety issues (and because
> that's ugly and I refuse :) ). Is there some thread state to which I
> have access from within a getattrofunc?
> 
> One disgusting possibility that occured to me was to modify the object
> being searched, temporarily replacing its tp_getattro member with a
> wrapper that would prepend the method semantics. I've temporarily shot
> that one down because it means I have to investigate what type of object
> it is, so I can apply the correct prepend (ie: a module might or might
> not support the "method" mechanisms I'm proposing). However, I'm willing
> to revisit that...
> 
> The other alternative is that I'm doing Something I Shouldn't Be
> Doing(tm).
> 
> -- 
> Tripp Lilley * tripp@perspex.com *
> http://stargate.eheart.sg505.net/~tlilley/
> -----------------------------------------------------------------------------
> "This whole textual substitution thing is pissing me off.
>  I feel like I'm programming in Tcl."
> 
> - Eric Frias, former roommate, hacking partner extraordinaire
> 
> _______________________________________________
> Compiler-sig mailing list
> Compiler-sig@python.org
> http://www.python.org/mailman/listinfo/compiler-sig

-- 
Greg Stein, http://www.lyra.org/