|
Size: 1724
Comment:
|
Size: 2250
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| Some project ideas that might work for Google's summer of code. The Python folks have very good advice for submitting proposals here: http://wiki.python.org/moin/SummerOfCode | Some project ideas that might work for Google's summer of code. The Python folks have [http://wiki.python.org/moin/SummerOfCode very good advice] for submitting proposals. |
| Line 6: | Line 6: |
| FrankWierzbicki | * FrankWierzbicki * JimBaker * CharlieGroves * MikeTaylor |
| Line 8: | Line 11: |
| == Help System == Note: This started as a weblog post from Brian Zimmer (His weblog disappeared a long time ago, but I dug it up again through the magic of the wayback machine. |
== AcceptedProjects == |
| Line 11: | Line 13: |
| One of the best features of Python IMHO is the help() function. It’s the first place I turn if I need help before I open a web browser and read the docs. | HelpSystem |
| Line 13: | Line 15: |
| I think it would be cool if we could do this: {{{ >>> from java.lang import String >>> help(String) }}} and see the full Javadoc documentation in help format. |
== Python 2.5 Language Support in the JythonCompiler == |
| Line 20: | Line 17: |
| I think a cool project would be to create a system that could turn source code comments into a format that the Jython help system could consume (perhaps with a Doclet if you have the source -- this will become especially nice for Sun's newly GPL'ed version) in the case of classes not already exposed with the special {{{__doc}}} string mechanism available in Jython already. | JimBaker and MikeTaylor are currently working on adding 2.5+ '''language''' functionality to Jython. We are trying to limit the scope of this work, just as was done with the AST implementation in CPython 2.5: |
| Line 22: | Line 19: |
| This could be facilitated with an xdoclet like framework which when ran over a source file would produce something Jython could use at runtime. This would either be a cached file or a Java class in a special namespace. For example, if you have class a.b.c.D then maybe the class a.b.c.D_doc might have the document source available through reflection. | * Write a generational grammar to build the desired AST in ANTLR 3. We may explore using a tree grammar to support enhanced visting. We think we might be able to just generate a comparable set of AST nodes as CPython, for enhanced compatibility. This is the easy part. |
| Line 24: | Line 21: |
| Of course, help() is not currently working at all in Jython -- so the first step would be to figure out why this is and fix it. Also, we need a strategy for getting the help documentation from CPython into our new style classes. | * Generate code using ASM; this would replace the current !CodeCompiler.java. This would be the bulk of the work. There's some interaction with the rest of Jython, but not too much (we think). More importantly, we need to identify some best practices on mapping Python constructs to JVM byte code, basically updating what JimHugunin worked out 10 years ago. We're also looking at two additional enhancements: * Move to using nested classes to represent methods. This just seems to be the right way to do it. Issues of PermGen seem to be just a red herring. We may be wrong, but it's the approach being taken by JRuby. * Favor "classworking" instead of reflection. ASM provides support here; JRuby is also looking at caching the necessary stubs. We would expect that there would be suitable subprojects in this that are suitable for the GSoC students. Some that come to mind: * Facilitate Java calling Jython, via class/method decorators and possibly annotations. * Construct translation, especially performance/correctness issues. (Subtle closure bugs still seem to be out there in CPython for example.) * Stub cache * Rolling up as part of the replacement to jythonc, using compileall, going to setuptools. All of these have the advantage that they can be completed to a certain implementation, and still be useful. /PotentialProjects |
Google Summer of Code
Some project ideas that might work for Google's summer of code. The Python folks have [http://wiki.python.org/moin/SummerOfCode very good advice] for submitting proposals.
Potential Mentors
AcceptedProjects
Python 2.5 Language Support in the JythonCompiler
JimBaker and MikeTaylor are currently working on adding 2.5+ language functionality to Jython. We are trying to limit the scope of this work, just as was done with the AST implementation in CPython 2.5:
- Write a generational grammar to build the desired AST in ANTLR 3. We may explore using a tree grammar to support enhanced visting. We think we might be able to just generate a comparable set of AST nodes as CPython, for enhanced compatibility. This is the easy part.
Generate code using ASM; this would replace the current CodeCompiler.java. This would be the bulk of the work. There's some interaction with the rest of Jython, but not too much (we think). More importantly, we need to identify some best practices on mapping Python constructs to JVM byte code, basically updating what JimHugunin worked out 10 years ago.
We're also looking at two additional enhancements:
Move to using nested classes to represent methods. This just seems to be the right way to do it. Issues of PermGen seem to be just a red herring. We may be wrong, but it's the approach being taken by JRuby.
- Favor "classworking" instead of reflection. ASM provides support here; JRuby is also looking at caching the necessary stubs.
We would expect that there would be suitable subprojects in this that are suitable for the GSoC students. Some that come to mind:
- Facilitate Java calling Jython, via class/method decorators and possibly annotations.
- Construct translation, especially performance/correctness issues. (Subtle closure bugs still seem to be out there in CPython for example.)
- Stub cache
- Rolling up as part of the replacement to jythonc, using compileall, going to setuptools.
All of these have the advantage that they can be completed to a certain implementation, and still be useful.