Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 02:12 AM 7/14/01 +0200, Samuele Pedroni wrote:
>First, for CPython 2.2 GvR is actively working on redesigning CPython
>internals (see PEPs 252,253) in order to remove the CPython type/class
>dicotomy, this will
>also allow to write CPython extension that result in class-like objects,
>e.g. subclassing from python will work. This will obsolete ExtensionClasses.

I'm aware of these efforts.  However, while they will eliminate the need 
for the "ExtensionClass" object itself, the various modules and classes 
written using ExtensionClasses will still need to exist (and will need 
rewriting).  For example, ComputedAttribute and MethodObject, two items I'm 
especially interested in porting to Jython.

I need these in order to have source portability for my TransWarp toolkit, 
so the API must be an exact match.



>[snip]
> > class ExtensionInstance(PyInstance):
>[snip]
>
>This makes really no sense (it is not intended to work), if one considers what
>the internal role of PyInstance instances is.

I don't understand.  I want to change the behavior of PyInstance - that's 
the point of ExtensionClasses, to be able to change the behavior of object 
instances in ways that can't be reached from Python.  I was just hoping to 
shortcut the process by using Python instead of Java to do it.

Being that the only way is to do it from Java, is there anyway to extend 
PyClass, while still having the meta-hook take effect?  I'd like to extend 
PyClass without having to copy all its code, just to get around the 
instanceof test.

Could there perhaps be instead a interface that Java extenders of PyClass 
could use to signal their desire to be a meta/pseudo-class?  Would a patch 
to the meta-hook that recognizes such an interface be acceptable?  Then I 
could subclass PyClass in Java, "implement" that interface, and everything 
would, I believe, be just fine.


>see above BUT in the future (2.2)
>jython will try to mimick as long as possible the new CPython redesign, this
>should results in more polished internals.
>That's the direction to go and work for, and as I said ExtensionClasses on the
>long run will become obsolete.

AFAICT, all that will go away is the need to have a full C reimplementation 
of the Python class type.  In order to do the things that ExtensionClass 
exists *for*, one will still need to extend PyClass, PyInstance, and their 
equivalents in CPython.  That is, unless features like __of__(), 
__class_init__(), inheritedAttribute(), __call_method__() and the like 
become part of the Python language standard, and I haven't seen any PEP's 
for them.