"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. PJE> and examination of bytecodes used in PJE> Python expressions. Okay, that's a tricky one :) 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. PJE> * Acquisition: Actually, not as difficult, compared to PJE> ExtensionClasses as a whole and persistence in particular, PJE> but it's still ExtensionClass based and probably a fair bit PJE> of work to do right. I talked about this in a previous post. PJE> In short, if you want a "JZope", you're going to have to work PJE> mighty hard for it. Or... if Pythons 1.6 through 2.0 move PJE> the ExtensionClass machinery, or something like it, into the PJE> base definition of Python.. AND the JPython folks follow PJE> suit... AND Digital Creations moves to the new "standard" PJE> extension machinery, THEN... a JPython port might be PJE> (somewhat) more "reasonable." 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. -Barry