At 01:44 PM 11/4/99 -0500, Barry A. Warsaw wrote:
"PJE" == Phillip J Eby <pje@telecommunity.com> writes:
PJE> * Reflection: Zope makes heavy use of Python internals, such PJE> as function metadata
Newer versions of JPython have a lot of the reflection attributes expected from CPython objects. Not all of course, and I don't know what Zope requires, but e.g. func_code, func_globals, func_defaults are all readable. Some reflection attrs that are writable in CPython may not be writable in JPython. I'd be interested to know what Zope requires here.
Check out ZPublisher's "mapply.py" for what ZPublisher needs. Basically, it needs argument names in addition to the above, which if I recall from JPython's docs is not currently available (i.e. co_varnames).
PJE> and examination of bytecodes used in PJE> Python expressions.
Okay, that's a tricky one :)
Yep. The DTML "expr" logic scans Python bytecodes looking for ones which access a variable name, then looks them up in co_varnames to get the name. The purpose is so that names referenced in a Python expression can be "hotwired" into a locals() dictionary when the expression is executed. This is necessary because CPython can't deal with the locals() part of an eval/exec being anything other than a 'pure' C dictionary object. If JPython doesn't have this requirement for eval/exec, a workaround may be possible. I think there may be other bytecode hacking done in the DTML classes done for security purposes, but I don't recall off the top of my head.
PJE> * ExtensionClasses: ZPublisher and DTML are the only parts of PJE> Zope that can work without ExtensionClasses (and DTML PJE> performance suffers without the MultiMapping extension). PJE> ExtensionClasses are C-based Python types which override PJE> object behaviors in ways that Python objects cannot.
It actually might not be hard to "port" or re-implement ExtensionClasses to JPython, esp. because you've got a real OOP underneath. It might be as easy as deriving from PyObject, implement the behavior you want, and then exporting this into Python as a class that can be derived from.
I didn't say it was impossible, just that you need to deeply grok both systems. I'm one of (I believe) relatively few people outside DC who claim even moderate grokking of ExtensionClasses, so that would seem to imply that the potential number of people who could implement a port correctly pretty small. (Especially since I don't even have a rudimentary grokking of how JPython's underlying shells work.) Here are the things a JExtensionClasses would have to do, that I know of: * Implement the __of__ hook (from what you've said, this probably isn't excessively difficult) * Implement the __call_method__ hook (requires __of__, plus a "PythonMethod" helper class) * Impliment inherited_attribute (or whatever the exact name is) * Implement __class_init__ (called when an ExtensionClass subclass' class/type object is first created) * Allow hooking __getattr__ at a level above the level which is normally allowed by Python (i.e., *before* the instance or class dictionaries are searched) Hmmm. Y'know, now that I'm really thinking this through step by step... it doesn't look quite as impossible as it first appeared. However, my first reaction to that thought is that it probably just means my grok of ExtensionClasses themselves isn't as good as I think. :) Mainly though, it's occurring to me that a lot of the deepest voodoo I know of in ExtensionClasses has to do with making C subclassable in C or Python, and keeping track of reference counts. Since JPython already makes the underlying language subclassable, and doesn't *need* reference counts... Hm.
It would be a very useful discussion to have. I'd like to see much more convergence in the reflection and extension areas of the two implementations.
The interesting bit seems to be this: if the truly hard work of ExtensionClasses has already implicitly been done in JPython, it might make it more reasonable for somebody with a deep JPython knowledge to worm the necessary remaining ExtensionClass knowledge out of the DC folks or persons like myself. My interest in the project is rather limited, in that Java's not a buzzword I currently need for any of my work. But if it's doable, it'd be an interesting curiosity. Of course, once Zope itself is up, there are still things like intSet and BTree that have to be converted from C, as well as the cOptimizations, cPickleCache, etc. Which I expect will all have challenges of their own. In other words, "the devil is in the details."