I added an example of how I'd do this and a test case that exercises
the example in r5940.  All of the method wrapping action is in

The basic technique is to create a subclass of PyBuiltinMethodNarrow
that has implementations of __call__ for the argument widths you're
after.  That new method is added to the PyJavaType for the class in
question to override its default behavior.  In the case of
__getattribute__ -  the method you want to use instead of __findattr__
from PyJavaClass - it grabs the PyObject version of __getattribute__
and first tries that to see if the class already has an attribute
under that name.  If it doesn't find an existing attribute, it returns
whatever the Map held by that class has for that name.  If that all
sounds pretty vague, I think the code makes it a little clearer.
PyJavaType itself also contains several examples of code like this.

Great, it looks like just the example that I need. I'll have a stab at 
recasting my code in these new terms tonight. (I will say that, in 
the meantime I seem to have managed to duplicate the functionality
that I need with subclasses of PyObjectDerived. But I'd like to do this 

One caveat is that this is still pretty deep in Jython's internals, so
it's possible that it'll change again in the future, even before 2.5
is released.  Once 2.5 is released, any code written using techniques
like this will work with further releases in the 2.5 series, will
hopefully work with the 2.6 release and most likely will need at least
a slight rejiggering for 3.0.  One of the big things we want to
accomplish for 3.0 is a clear separation between public and internal
APIs in Jython's Java code, but it isn't going to happen for 2.5.

Understood. That said, I've actually enjoyed the current state of affairs  
being able to work my code well into the cracks of Jython's 
code-base. I embed Jython with a custom dict for globals, a custom 
classloader, a custom ObjectAdaptor and with a lot of deep inspection into 
PyMethods and the like  it makes for a remarkable level of integration 
between Jython and Java. I'll take comprehensible internals that change 
occasionally (with warning) over a fixed, conservative API any day.
> I'll swap you that for a nasty little corner-case NPE in beta-1's
> MRO-computation that I'm currently trying to turn into an isolated
> example...

Thanks!  I guess I'll dig into that now...

It's http://bugs.jython.org/issue1234, but if I had a vote, I'd say that 
http://bugs.jython.org/issue1230 is a much bigger show stopper. Had I 
not been able to hack around that one I would have had to stop tracking 
Jython beta's in my work. 

In any case, thanks for the help!