[Compiler-sig] Re: [selfish-devel] Ugly hacks: modifying instance_getattr

[echuck@mindspring.com]

You have lost me. Why do you want to hack on "obj.foo()"?


Tripp Lilley <tripp@perspex.com> 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
_______________________________________________
selfish-devel mailing list
selfish-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/selfish-devel