[FRPythoneers] Jython Sprint (Re: jython hacking anyone)

Jim Baker jbaker at zyasoft.com
Mon Dec 11 11:22:13 MST 2006


After all of this, I can see that Jython development is currently rather 
disorganized. But here 
<http://headius.blogspot.com/2006/11/jython-alive-and-well-and-looking-for.html> 
is one compelling blog entry to say it's not dead yet, it's just looking 
for love. And Jython is certainly a juicy project. People are still 
actively using it, there's some interesting technical challenges, and in 
this one, we see substantial org challenges to overcome as well. So 
should the Pythoneers adopt this adorable puppy?

With this in mind, what if we plan in the following way:

Jan 6, Feb 3 (Saturdays 9 AM - 6 PM) - we hold BoulderSprint 
<http://wiki.python.org/moin/BoulderSprint>, to prepare and otherwise 
plan for
Feb 26 - Mar 1 - 4 day sprint at PyCon 
<http://us.pycon.org/TX2007/Sprints> on Jython - I just added an entry 
for it
 
What sort of preparation?

Kip's comments are very relevant, because they suggest that we really 
have an engineering problem here. I really like the idea of a 
scoreboard; this would add a lot of value to Brian Zimmer's proposal 
<http://wiki.python.org/jython/MovingJythonForward>. Here are a few 
other ideas:

Design. One insight I got from the Django-Oracle sprint is the value of 
design. Well, no one questioned that, but what we saw was the input of 
design _even late_ into the process with respect to supporting Oracle. 
We had enough experts in the room to resolve definitively some open 
questions - or redress some ones that had not been done satisfactorily 
before. So some design issues to be addressed for Jython would be byte 
code translation of Python features, possibly via an intermediary like 
Janino <http://www.janino.net/use.html>; requisite modules; etc. (I was 
looking at the list of missing modules 
<http://wiki.python.org/jython/AbsentModules>, and there was Bastion 
<http://docs.python.org/lib/module-Bastion.html>, disabled as of 2.3...)

Testing. And if we are doing design up front, why not testing too ;). So 
here's one addition to having an effective test-driven process. It would 
be nice if Jython were in the Pybots <http://www.pybots.org/>. I mean, 
why should Jython be chasing CPython constantly, when it comes to pure 
Python code? Complex projects like Twisted and Django have their 
dependencies too, and that's why they're in Pybots. My intuitive feeling 
is that Jython should not be converging on CPython 2.3 but on 2.6.

Designate a champion. As for a big sponsor, a white knight, my feeling 
is that is not going to happen until after some progress is made, if 
even then. (But Sun could still sponsor 
<http://us.pycon.org/TX2007/HowToSponsor> the PyCon sprint.) Still, if 
we get the participation of a company or group out there that's actively 
using Jython, that would add significant focus, just as Array Biopharma 
helped on the Django-Oracle sprint.

- Jim


Kip Lehman wrote:
>
> Although my modest Java skills are rusting away each day, I'd be 
> interested in
> doing some Jython hacking.
>
> Here are some thoughts about what is needed to propel Jython to a 2.2 
> beta
> and final release
>
> o  Jython status communication
>
>   The likelihood that you, unless you are a core Jython developer,
>   know what components are complete in Jython for a 2.2 release is
>   quite small.  Why?  There appears to be no publicly available
>   and easily digestible record of what is done, what is being worked
>   on (and how far along it might be) and what remains to be done.
>
>   A starting point might be to segment the product into a handful
>   of categories (with some subcategorization) and put up a
>   red/yellow/green scoreboard for each item on the Jython web-site.
>   What might those categorizations be?  later...
>   There is a Jython wiki page that might be an appropriate target for 
> this.
>   Having some rudimentary form of project status tracking might be
>   helpful in terms of bringing in additional help.  If you don't know
>   what needs to be done or fixed, you might not want to volunteer your
>   time.  Knowing specific areas or items that are in need of attention
>   and have a close relationship to your area of interest/expertise could
>   be a catalyst for involvement and action.
>
>      strawman categories:
>          core language capabilities (new style classes, slots, 
> generators, etc.)
>          modules
>          Java version compatibility
>          installer
>          GUI development/usage/examples
>          Jythonc
>          Web related considerations (server side, client side?)
>          applet related considerations (environment, howto, examples)
>
>
> o  Classpath / invocation environment issues
>
>    Having observed the Jython mailing for some years, a repeated topic
>    of confusion is one related to setting the CLASSPATH, using jars and
>    how to properly reference jars/dirs in manifests.
>    Providing a primer on how to operate using the different constructs
>    and some pointers on the decision making process of when and how to
>    use said constructs would be a valuable addition to the Jython
>    community.
>
> o   Improving coverage and awareness of Jython environments.
>
>        Jython 2.1 supports Java 1.2 through Java 1.5
>        Jython 2.2x is slated to support Java 1.2? through Java 1.5 .
>        Java 1.6 has either had an alpha release or such a release
>        will occur within the next 3 months.
>
>        Identifying features and capabilities within Java 1.5 and 1.6
>        that would be candidates for exploitation from Jython or need
>        documentation to introduce/explain them to Jython developers
>        would be helpful and a good advertisement for Jython.
>
>        Results of running the Jython test suite on various platforms/
>        JVM versions could provide a one-stop shop for those wondering
>        if Jython could work in their environment and also serve to
>        display the wide range of Jython applicability.
>
> o   Jython installation package
>
>        Unknown what state the 2.2x version is in.  My recollection is
>        that the 2.1 version was characterized as not being suitable
>        for continued use.  A Jython installation package that can:
>
>          1) be configured/scripted for large scale installations
>             (aka headless)
>
>          2) offer novice users a GUI with helpful explanations of
>             installation choices and the opportunity to return and
>             modify those choices
>             (aka headed)
>
>        would be a important component in polishing the Jython image.
>        It could be that most of the work for the new installer is
>        done and that testing activities would be the most important
>        contribution.
>
>
> o   Jython and web-services / SOAP
>
>        Python SOAP implementations seem to offer only limited coverage
>        and the documentation can be somewhat difficult to comprehend.
>
>        Java web-services implementations seem to have a wider range
>        of capabilities and larger operational acceptance.
>        Leveraging some of the better Java web-services products with
>        Jython might be a niche that could widen and diversify the
>        Jython community.
>
> o   Jythonc
>  
>        My impression from sporadic reading of the jython-dev mailing
>        list is that jythonc isn't going to be a workable part of 2.2.
>        Documenting the state of jythonc 2.1 and the problematic areas
>        that prevent its completion in 2.2 would at least provide
>        the community with valuable information.
>
> -- 
> Kip Lehman
> kipster<dash>t<at>earthlink<dot>net
> _______________________________________________
> This message sent by the FRPythoneers mailing list.
> Unsubscribe: echo unsubscribe | 
> FRPythoneers-request at lists.community.tummy.com
> URL: http://lists.community.tummy.com/mailman/listinfo/frpythoneers
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.tummy.com/pipermail/frpythoneers/attachments/20061211/eb9012df/attachment.html>


More information about the FRPythoneers mailing list