Differences between revisions 22 and 24 (spanning 2 versions)
Revision 22 as of 2007-04-13 00:59:12
Size: 7162
Comment:
Revision 24 as of 2007-04-27 13:03:04
Size: 5857
Editor: ptah-gw
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
HelpSystem == AcceptedProjects ==
Line 13: Line 13:
== Jython unit testing == === HelpSystem ===
Line 15: Line 15:
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:
by Ryan Morillo, mentored by Charles William Groves
Line 18: Line 17:
 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
I would like to work on geting the help system to work on Jython, working on figuring out why the python help system doesn't automatically work, then either adjusting the CPython code so it works on both systems, or implimenting it nativly in Jython, barring either of those, writting it in Java and making it part of Jython distrobution. After getting help to work normally, I expect to work on Jythons import, to get it to pull the javadoc and translate it to python help in place with a lazy hook that is called with help()
 
 The main reasons I would like to work on this project are my enjoyment of the python language, being able to give something back to the first real language I learned, and adding a major tool to the proliferation of this wonderful tool for new programmers and developers needing the speed and information they require to use Jython to it's full potential.
 
 Some qualifications and experience:
 I have been a python evangelist for eight years, linux user for seven, Microsoft since dos 3.1, Java for two, and have recently finished my AA on my way to getting my B.S. in computer science or computer information systems (Undecided due to math vs. work and sleep)
 I've mostly been self taught, but have vigorously pursued programming knowledge both in school, and by developing and reading my library of language references, data structure, theory, and domain specific books.
 Working for a multinational company, doing reports analysis work; I developed code to the point I worked myself out of the analyst job by generating the reports, documenting the interface and logic so that a secretary for the division was able to implement the project manager's changing needs so he was able to have the data in a succinct enough form that I was moved to another position at that company's command center.
 
   
Line 24: Line 28:
== 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.
  http://www.google.com/search?hl=en&q=%22coding+in+the+debugger%22

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:
  http://msdn2.microsoft.com/en-us/library/bcew296c(VS.80).aspx
 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.
  http://mail.python.org/pipermail/edu-sig/2007-February/007776.html

Guido said it was "impossible",
  http://mail.python.org/pipermail/edu-sig/2007-February/007794.html
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."
  http://www.des.emory.edu/mfp/impossible.html

--Paul Fernhout

== Python 2.5 Language Support in the JythonCompiler ==
=== Python 2.5 Language Support in the JythonCompiler ===
Line 116: Line 50:

=== Python 2.5 Language support in Jython ===

by Tobias Ivarsson, mentored by James Edward Baker

The JVM is a great platform, it is widely used, available on many devices and there are a lot of great libraries and applications available on the JVM. Python is a great programming language, it is well suited for rapid development, prototyping and agile development methods. Jython unites these two great systems. Sadly Jython is not in an up to date state at the present time. To aid this Jython needs to be brought to a state where it is compatible with the latest version of Python. That is what this project aims at. I will provide work on the parsing of Python code and generation of byte code for the JVM. Ideas for solutions can come from the latest CPython implementation, and other implementations of dynamic languages on the JVM, such as JRuby or Groovy.

=== PyPy JVM backend advancements and integration with JSR-223 ===

by Paul deGrandis, mentored by Antonio Cuni

The recent advancements of PyPy have been impressive to say the least. Much work as been done to provide a JVM backend, but it still lacks full completion of finer details. The goal of my summer of code project will be to work at the remaining problems to achieve a level stability that is fitting to be used with JSR-223 (the Java Scripting addition) and Java6. Doing so will allow PyPy interoperability with Java, Scheme, Python, JavaScript, Ruby, and many more languages that implement this JSR specification. Additionally, should time allow, an empirical experiment will be conducted to show the PyPy's affect on developer efficiency in an academic setting using the JVM backend and JSR-223 bridge.

/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

HelpSystem

by Ryan Morillo, mentored by Charles William Groves

I would like to work on geting the help system to work on Jython, working on figuring out why the python help system doesn't automatically work, then either adjusting the CPython code so it works on both systems, or implimenting it nativly in Jython, barring either of those, writting it in Java and making it part of Jython distrobution. After getting help to work normally, I expect to work on Jythons import, to get it to pull the javadoc and translate it to python help in place with a lazy hook that is called with help()

  • The main reasons I would like to work on this project are my enjoyment of the python language, being able to give something back to the first real language I learned, and adding a major tool to the proliferation of this wonderful tool for new programmers and developers needing the speed and information they require to use Jython to it's full potential. Some qualifications and experience: I have been a python evangelist for eight years, linux user for seven, Microsoft since dos 3.1, Java for two, and have recently finished my AA on my way to getting my B.S. in computer science or computer information systems (Undecided due to math vs. work and sleep) I've mostly been self taught, but have vigorously pursued programming knowledge both in school, and by developing and reading my library of language references, data structure, theory, and domain specific books. Working for a multinational company, doing reports analysis work; I developed code to the point I worked myself out of the analyst job by generating the reports, documenting the interface and logic so that a secretary for the division was able to implement the project manager's changing needs so he was able to have the data in a succinct enough form that I was moved to another position at that company's command center.

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.

Python 2.5 Language support in Jython

by Tobias Ivarsson, mentored by James Edward Baker

The JVM is a great platform, it is widely used, available on many devices and there are a lot of great libraries and applications available on the JVM. Python is a great programming language, it is well suited for rapid development, prototyping and agile development methods. Jython unites these two great systems. Sadly Jython is not in an up to date state at the present time. To aid this Jython needs to be brought to a state where it is compatible with the latest version of Python. That is what this project aims at. I will provide work on the parsing of Python code and generation of byte code for the JVM. Ideas for solutions can come from the latest CPython implementation, and other implementations of dynamic languages on the JVM, such as JRuby or Groovy.

PyPy JVM backend advancements and integration with JSR-223

by Paul deGrandis, mentored by Antonio Cuni

The recent advancements of PyPy have been impressive to say the least. Much work as been done to provide a JVM backend, but it still lacks full completion of finer details. The goal of my summer of code project will be to work at the remaining problems to achieve a level stability that is fitting to be used with JSR-223 (the Java Scripting addition) and Java6. Doing so will allow PyPy interoperability with Java, Scheme, Python, JavaScript, Ruby, and many more languages that implement this JSR specification. Additionally, should time allow, an empirical experiment will be conducted to show the PyPy's affect on developer efficiency in an academic setting using the JVM backend and JSR-223 bridge.

/PotentialProjects

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