>>>>> "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