Differences between revisions 19 and 21 (spanning 2 versions)
Revision 19 as of 2007-03-12 00:21:07
Size: 8419
Comment:
Revision 21 as of 2007-04-12 17:37:28
Size: 8429
Editor: rh72
Comment: Added page link
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
 * MikeTaylor
Line 109: Line 110:
== Python 2.5 Language Support in the Jython Compiler == == Python 2.5 Language Support in the JythonCompiler ==
Line 111: Line 112:
JimBaker and Michael Taylor 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: 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:

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. A project to clean out and modernize the bugtests (as well as the Jython specific unit tests under Lib/test) is definitely in order. The project could proceed through several steps:

  1. Determine if tests currently giving warnings are valid and need to be fixed or if they should be removed
  2. Break tests into groups for jythonc, Java integration, Jython specific functionality, and any other groupings that make sense after going through the tests
  3. Rename the tests with descriptive names instead of numbers
  4. Use unittest where possible instead of the custom driver.py code
  5. Hook the bugtests into the buildbot through the Ant build

Overhaul the documentation

The website (and this wiki) have an enormous amount of outdated (and sometimes just wrong) material -- the docs could use a careful re-write.

(Please check with the SoC coordinator and Google first. I believe that Google wants to fund the creation of code, not documentation, and am not aware of any documentation-only projects that were funded in past years. the project is certainly worth doing, of course. --amk)

Reloading in Jython

Note: this was copied directly from a post by Paul D. Fernhout to jython-dev

How about being able to modify and restart code in a debugger thread? Part of this entails allowing restartable / resumable exceptions.

Most Smalltalks support this, and it greatly increases productivity in some cases.

For example, consider when you run a Jython-based simulation for an hour only to get an exception from a trivial typo which such a debugging system would allow you to easily correct and restart from. Instead, you need to restart the code and wait another hour for the next typo. Yes, you can try to write your code to work around this sort of problem with checkpoints and events and such, but should not this be made easier, especially for beginners? A less extreme situation is when you are processing, say, an XML file, which takes a few minutes, and you need to keep restarting with each change. Anyway, not being able to restart easily decreases Python programmer productivity.

There is also a style of "coding in the debugger" where you write stubs for functions and just flesh them out while running the program.

To look at this more generally, essentially you are adding the capability to Python / Jython to "edit and continue" -- which might include writing a PEP, likely modifying Jython (and maybe Python), and modifying a GUI to use the changes (e.g. PyDev might be a good choice).

Smalltalk (including Squeak) has had this since the 1970s, but even Visual Basic can do it these days:

  • From there: "Edit and Continue is a time-saving feature that enables you

to make changes to your source code while your program is in break mode. When you resume execution of the program by choosing an execution command like Continue or Step, Edit and Continue automatically applies the code changes with some limitations. This allows you to make changes to your code during a debugging session, instead of having to stop, recompile your entire program, and restart the debugging session."

It's a shame Python and Jython can't do what even Microsoft products can. And no, module reloading (even using xreload.py or the code I previously posted on it) is not general enough to be able to modify a running thread and resume with all the old variable values with the new code. Xreload or the code I posted is general enough to modify code in a running GUI application, but only only for future GUI events (not one currently having problems).

You can see related recent comments on this in the Python Edusig list, starting here.

Guido said it was "impossible",

so it would make a nice challenge for someone (perhaps even moving Jython ahead of Python in some ways. :-) No guarantee of success, but a worth effort which would certainly require someone to learn the core of Jython and how it does exception handling. For inspiration, see:

--Paul Fernhout

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.

SummerOfCode (last edited 2012-01-21 02:13:50 by SkipMontanaro)