Re: [Jython-users] where to go from here...get the PSF proposal right!

[Paul D. F. <pdf...@ku...>]

Walter Chang wrote:
 > [snip]
> The fact remains that we have a PSF grant that we failed to
> execute....so money is not the big issue yet (it's always an
> issue...even for us :-)
> 
> If our original proposal was off, we should correct it and see about
> getting a better quote for hours/dev time.
> 
> Then publish it and get going...we have a really good product that I
> believe is way ahead of the game when compared to groovy, beanshell,
> jruby...but for widespread adopment we have a long way to go...
> 
> P.S. is 50k even enough to get us to 2.4.2 ?  we should think hard and
> long about what 2.4.X means before we say "yes"

You raise a lot of great issues.

I feel the original grant proposal was ambitious for the funds as far as 
covering all of the development; at best that small amount of money is 
just defraying part of the cost. In that sort of  situation, the risk is 
higher things won't get done if other stuff comes up in the developer's 
life. I would think the work outlined (plus the implicit work of testing, 
communicating, etc.) was closer to a year full-time, and $10K or whatever 
was just a small fraction of that. Now don't get me wrong; I think it was 
a good grant to give, a good choice of person, and the PSF made an 
excellent overall strategic choice (and I say that as one who had a 
rejected grant proposal on a Delphi->Python conversion tool, the PSF 
choice was better). So it was a good risk to take. It did not pay off 
completely, but it certainly got progress in a strategic area more than 
proportionate to the investment, so it was worth it for PSF grant dollars 
as it did "move Jython forward".

But here is the bigger risk in any sort of small grant or paid work -- and 
it is exactly what you are outlining -- there arises the expectation 
someone is being paid to be responsible for the whole project. Now that is 
fine if you have a situation like Guido or others for mainline Python -- 
full time jobs at research institute. But for small amounts of money, 
unless the person is already the originator of the project and heavily 
invested in it (e.g. Robin Dunn and wxPython), the level of ongoing 
support you are going to get is more questionable in such situations. 
Further, putting money on the table may have the psychological 
disadvantage of discouraging other people for various reasons. So in this 
sense, the Jython grant, like any small such grant, may have had some 
negative community effects. This is less of a problem when supporting 
standalone projects that are just hurdles to get over, as opposed to in 
this case a large effort that needs continual involvement if it is to 
track the mainline of Python. Overall, I still think it was a good grant, 
and a good direction for PSF funds, I'm just pointing out how the 
potential negatives link into the current situation so we can go forward 
with it.

I think one of the other issues with the Jython project in particular is 
that using Java as a free software platform is questionable in the minds 
of a lot of open source / free software developers. Google on "The Java 
Trap" for example.
   http://www.gnu.org/philosophy/java-trap.html
Obviously Java is now, after many years of development, finally a stable 
enough platform for commercial use, but it remains a gray area as far as 
having truly open source versions which are complete and easy to use (e.g. 
GNU class path is incomplete, Sun's Java isn't trivial to install on 
Debian or some other distributions because of licensing issues, etc.). So 
Jython, being on Java, is just not going to attract the same level of free 
dedication as Python on C/Unix. The same issue comes up in level of free 
software support for MS Windows vs. GNU/Linux. Jython is in that sense a 
more "commercial" oriented product than Python, because Java is a more 
commercial platform because of Sun's strategy than C/wxWindows/etc. So 
perhaps it is not unreasonable to think Jython's development and support 
might have more issues to work out because of all that, and more 
commercial support of it might be needed.

Here is a  a personal example of making such a choice from a free software 
perspective. I have finally made a rudimentary Delphi->Python translator 
to translate a few free Delphi projects we have (using ANTLR and a Delphi 
grammar I cobbled together, and still requiring significant hand tweaking 
afterwards related to GUI issues, etc., etc.), with some support for 
generating a Jython GUI from Delphi GUI specifications. But, I am still 
debating in my mind whether to use the code the translator outputs for 
Jython by beginning the hand fix up the output, or to instead make some 
minor alterations to the translator to instead output plain Python and 
target wxWindows. Why? My wondering is on the ground that there might be 
more developers willing to support a Python/wxWindows result and that it 
would be easier for the average end user to install a Python version than 
expecting them to have the right version of Java, the right set up with 
their classpath, and so on. On the other hand, I can also ask, where will 
the GNU classpath project be in a year or two, or will Sun finally truly 
open up Java? If these were commercial projects I was translating at this 
point, sticking with Jython would be an easy choice, but the free nature 
of the projects makes it more questionable. Anyway, so while not exactly 
the same as your situation, there is similar frustration there -- Jython 
is really neat, but Java solutions don't have the same level of free 
software / open source support that C or plain Python do. Still if you 
*must* use Java (especially in an enterprise situation), then Jython 
obviously is the best game in town, but then, you still have the 
frustration about the level of free support for a project built 
essentially on a commercial platform. In that sense though, you could 
argue the cost of supporting Jython development as a business expense is 
really built into the choice of Java as a platform more than it is built 
into the choice of Jython (which is a no-brainer IMHO if your on a Java 
platform. :-)

Also, it seems that enthusiastic cutting-edge Python development has been 
moving to the PyPy model (writing Python in a subset of Python and then 
translating it to C or whatever).
   http://codespeak.net/pypy/dist/pypy/doc/news.html
Squeak Smalltalk does something similar with great success.
   http://minnow.cc.gatech.edu/squeak/2267
So it would seem that the future of any Python system on another platform 
might lie more in that area, than in just maintaining a separate codebase. 
If I like Jython because it hides Java, it's sad to then have to to 
wrestle with wading through endlessly verbose and repetitive and 
inconsistently indented Java to improve Jython (not intended as a slight 
on the Jython codebase, just a slight on Java :-). Not that one can't do 
it -- it's just not that much fun. :-( A PyPy->Java solution might 
eliminate most of that issue of having to write and maintain much Java. 
Obviously there would remain some Java specific to the project, and there 
would be new PyPy ones I'm sure, but a lot of maintenance headaches in 
tracking CPython might just go away, and PyPy might also benefit from the 
extra attention. On the other hand, supporting PyPy and translation 
requires a different and more abstract mindset, which might reduce the 
number of developers who could work on the codebase. (One could also use a 
python grammar and something like ANTLR to generate either C or Java to 
produce some commonality as another approach,
   http://www.cs.usfca.edu/~parrt/course/652/labs/python.html
but PyPy really has the momentum behind it).

On a practical basis, I think there are other Jython issues related to 
ambition. Jython still targets lesser VMs for 2.2/2.3/2.4. Personally, I 
think 1.4 is the least a future version of mainline Jython should target, 
given limited community resources, and one could make a good argument for 
just supporting Java 1.5 (i.e. if Jython is wedded to Java, just live with 
Sun's issues). Obviously 2.1 could be maintained for lesser JVMs. A big 
issue here is simply testing on multiple platforms and dealing with buggy 
older JVMs, not taking advantage of language features.

So, is $50K enough to get to 2.4.2? I don't know. It's probably enough to 
get a semi-volunteer in the US to spent a year full-time on Jython getting 
it as far as possible. (I know I'd be tempted, but frankly there are 
probably better choices from the people already maintaining Jython, plus 
offshoring would probably get two or three developers for that. :-). What 
that year of such effort would result in would be more questionable, but I 
would think 2.4.2 (plus XML & threads etc.) would be a reasonable target, 
perhaps even for just half that effort. But, as I pointed out, there is 
this new tension with PyPy becoming of growing importance, and it might 
even possibly make more sense and be less work overall to just augment 
PyPy to spit out Java and do some glue work for that than to try to 
maintain and upgrade a pure Java codebase. (Now that's the kind of thing 
someone like myself would get really excited over. :-) I'm not saying that 
PyPy approach does make short-term sense (because I haven't spent much 
time with either PyPy or all the intricacies of the Jython codebase), and 
it also would be more risky in some sense compared to patching an existing 
codebase, just that it is an issue to explore, as it has the potential to 
greatly reduce the maintenance overhead of Jython, as well as simply being 
more fun (an important factor in open source / free software).

Anyway, that's just my two cents from the sidelines; I'm sure other people 
would have better informed opinions on this.

--Paul Fernhout