reverse Jython

[Tony Meyer]

> PyPy, given the secret belief, will make a good project, on-going 
> project, collaboration project. The problem lies with the nature of a 
> thesis work or any academic project, what academics aims for is to 
> publish papers, get money and work on an area.

I am sure that you could publish papers about (suitable) work on PyPy.
Getting money is not likely to be as easy, but then academic funding is
never easy.  IMO, work isn't that relevant - you're unlikely to ever get
work that directly follows from thesis work; you look for work in similar
areas, where your expertise is still relevant.  There are bound to be PyPy
subprojects that would include such expertise.

> With a large project like PyPy, the dynamics of academic 
> research breaks down as it is real tough to carve a boundary of
> that you want to do.

It's possible to find a small part of any large project to work on,
otherwise they'd never get completed.

> For example, if I say (announce on usenet) that I am working import 
> mechanism, I will be hoping that nobody in this world will write the 
> same thing before I am done with my thesis. If someone did 
> that before me, then the chances of publishing my work drops to near
> zero.

This isn't really a problem in practice, unless you choose something that a
*lot* of people want to do, and indicate how you are likely to do it.  It's
no different than announcing what you are working on in a journal - that
doesn't mean that everyone that reads the journal article is going to try to
beat you to it.  I would think that PyPy is probably *safer* in this respect
than many other projects, particularly if you did tell the PyPy people that
you were planning to do this (I assume that they are both courteous and
uninterested in duplicating work).

I don't know enough about either PyPy or your interests/expertise to know
whether PyPy would be a good choice for you, but the above is not valid
reasoning.

=Tony Meyer