|
Size: 1588
Comment:
|
Size: 2385
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 | 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 == FrankWierzbicki |
| Line 6: | Line 9: |
| 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. | 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 [http://www.archive.org/web/web.php wayback machine]. |
| Line 17: | Line 20: |
| 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) runtime Javadoc parsing (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. | A good project would be to create a system that could turn Javadoc comments into a format that the Jython help system could consume (perhaps with a Doclet or xdoclet?) -- 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. |
| Line 19: | Line 22: |
| 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. | This could be facilitated with an xdoclet like framework which when ran over a source file would produce something Jython could use at runtime. |
| Line 22: | Line 25: |
== Jython unit testing == Jython has two sets of unit tests -- one which is comprised of the CPython tests and a number of Jython specific tests written in a similar style. The other is the "bugtests" directory -- which contains just short of 400 tests which are numbered test000.py to test394.py. The bugtests are peculiar to Jython -- they do many things that just wouldn't make sense in a CPython context. For example, the bugtests have support for compiling java source files as part of the testing. I think a project could be made to migrate the bugtests (as well as the Jython specific unit tests under Lib/test) to a style closer to the modern CPython tests (for example, the bugtests should be an extension of unittest instead of being so custom). Also, I wish the bugtests tests had descriptive names instead of the testXXX numbering. |
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
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 [http://www.archive.org/web/web.php wayback machine].
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.
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.
A good project would be to create a system that could turn Javadoc comments into a format that the Jython help system could consume (perhaps with a Doclet or xdoclet?) -- 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.
This could be facilitated with an xdoclet like framework which when ran over a source file would produce something Jython could use at runtime.
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.
Jython unit testing
Jython has two sets of unit tests -- one which is comprised of the CPython tests and a number of Jython specific tests written in a similar style. The other is the "bugtests" directory -- which contains just short of 400 tests which are numbered test000.py to test394.py. The bugtests are peculiar to Jython -- they do many things that just wouldn't make sense in a CPython context. For example, the bugtests have support for compiling java source files as part of the testing. I think a project could be made to migrate the bugtests (as well as the Jython specific unit tests under Lib/test) to a style closer to the modern CPython tests (for example, the bugtests should be an extension of unittest instead of being so custom). Also, I wish the bugtests tests had descriptive names instead of the testXXX numbering.