Charlie Groves wrote:
> On 5/11/07, Frank Wierzbicki <fwierzbicki@...> wrote:
>> Must do:
>> * Replace Jythonc's current implementation with one based on
>> compileall.py and the core compilation process.
> There are a couple big parts of this that deserve their own bullets:
> * Turn a Python class into a Java class.
> Jythonc uses Java type information in Python method docstrings to
> expose appropriate Java methods. That can be done without annotations
> for methods by having a Jython class implement a Java interface, but
> we need a way to handle constructors too. Essentially, Java code needs
> to be able to reference a "Class" for a Jython class and instantiate
> it. I'm not sure if that requires the full type annotation in an
> __init__ docstring, or if we can have an abstract class with a
> constructor that the Python class must extend. It'd be really nice if
> we could come up with a sane way to name these Python classes so they
> could be referenced with Class.forName in Java.
> * Statically compile proxy classes for Python classes that extend Java classes
>> * Remove ClassDictInit in favor of the new style class way (typeSetup,
>> etc). Make all classes that are exposed to the Python layer
> InitModule is in the same category as ClassDictInit.
> I agree that a typeSetup like mechanism is the way forward, but it
> needs some serious bullet point level work:
> * Remove the use of reflection in typeSetup. PyType uses reflection
> to find and invoke the various pieces of typeSetup. This eats up a
> substantial portion of our startup time. A TypeSetup interface that
> had methods for each of the pieces could really speed this up. Each
> type has a class that goes along with it that implements the TypeSetup
> interface and an instance of that is passed into PyType instead of the
> Class to avoid reflection altogether.
> * Replace the templating system. I've encountered extreme obstacles
> extending the templating system to do minor new things. Changing its
> fundamental output would be extremely difficult.
well, I think is problem number one is that it is inner workings are
undocumented, OTOH I don't think
I can spend time solving that.
> Beyond that, I don't
> like the way it inserts huge gobs of source into our basic types, that
> it requires users to learn an arcane type declaration syntax, that the
> type declarations are in a separate file from the regular source and
> that it is an additional step before compilation.
> I've been thinking through a system that uses Java 5 annotations and
> bytecode creation to replace it. Basically, you would add @exposed to
> every method and field you want to be visible to Python. The
> annotation takes elements to further specify type coercion, error
> messages and default values if they can't be inferred from the method
> arguments. A processing system would run through the annotations and
> emit bytecode for a class implementing the TypeSetup interface I
> described above. It would contain inner classes very similar to the
> classes currently in the generated typeSetup method. I think this
> gets around all of the problems I list above at the cost of not being
> able to see the generated source.
I think the good thing to this would be the reusing of what the platform
OTOH I fear the necessary java code would still be quite opaque, I would
not underestimate the amount of work to do this. We cannot win here,
both Python and Java are not especially good at expressing code generation.
I think we need tools that people can be comfortable with, I also hope
that each new generations of maintainers will not end up rewriting this
stuff from scratch.
> * Add support for modules to typeSetup.
>> * Make the modules implemented in Java consistent (there are currently
>> at least two styles in the codebase: everything in one class (see
>> math.java) , and separating a module into a Java Package (see sets))
>> I favor the second way.
> This should come along with the typeSetup work above.
> There are a few more things I'd add to the must do list:
> * Remove all code that's only for jythonc. There's a fair amount of
> stuff for it in Py.java and in the frozen jythonc support.
> * Reorganize and clean out the bugtests.
>> Should do:
>> * Replace old collections (Vector, HashTable) with new collections
>> (List, Map). Probably have to use the synchronized versions in most
>> cases to preserve the thread safety...
> I ran Jython under a profiler a few weeks ago while looking at the
> generated bytecode to see where we spend all of our time.
> PyStringMap, our __dict__ and globals, uses System.identityHashCode as
> its hash mechanism which is really really slow. I ripped out the
> custom hash stuff in there and replaced it with a standard Java
> HashMap and it sped things up considerably. I didn't actually commit
> it since there are a few things PyStringMap does that don't translate
> directly into Map calls, but it looked possible and will be a nice
> speedup for many things. I'll definitely finish investigating it in
> the 2.5 timeframe. I imagine we could get some similar speedup
> through replacing the older collections.
> I only have one additional point for should do:
> * Rework Java integration to eliminate reflection. We use reflection
> to look at the methods on Java code and make calls on them from
> Python. As with typeSetup, this could be greatly sped up by making
> the calls directly. Also, the Java integration is extremely
> convoluted so cleaning this up could be valuable on its own.
I would you support accessing java classes without reflection in a
scenario where you cannot
create classloaders and load bytecode? notice that knowing beforehand
which classes some code
is subclassing is quite different to know all the java classes it may
potentially interact with at runtime.
About cleaning up the java integration is probably the area I plan to
spend some of my own time to help out
for the next release.
>> May do:
>> * Re-format code to follow Sun's guidelines for Java and CPython's
>> guidelines for Python.
> I think establishing a code formatting policy and then implementing a
> "format it when you touch it" rule would be about right. There are
> significant pieces of code that have meaningful formatting that an
> auto-formatter would destroy. I'm fine with following the Sun and
> CPython standards.
>> * Comment the code better, especially the Java -- it would be nice if
>> there where at least a descriptive comment at the top of each class.
> In a similar vein, I vote for a "comment it when you touch it" rule.
> I like to make method names as intentional as possible to avoid
> excessive commenting, so I feel like we should just aim for Javadoc on
> all public and protected api methods and comments beyond that for
> non-obvious bits.
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> Jython-dev mailing list