Differences between revisions 22 and 23
Revision 22 as of 2007-04-13 00:59:12
Size: 7162
Revision 23 as of 2007-04-17 05:03:50
Size: 2250
Editor: c-71-204-163-42
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
== AcceptedProjects ==
Line 12: Line 14:

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

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:
  "What's that you say? Impossible, is it? We'll just see about that."

--Paul Fernhout
Line 116: Line 37:


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



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)