That's a great question!
Currently in my own Jython development work I'm focused on
the blocker for beta 2: pip support. Jython 2.7 must
have support for the standard tools in the Python ecosystem.
Of these, pip - and related virtualenv and easy_install - are
absolutely critical. The pip tool in turn requires the
requests package, which in turn requires support for
It's been much more involved than we hoped, but this branch
is currently converging on such support: https://bitbucket.org/jimbaker/jython-socket-reboot
currently at least 2/3 of the tests in test_socket pass,
beyond the fact that it supports SSL (including Start TLS) .
Remaining work includes support for pseudo socket options and
similar relatively minor bits & pieces. (It's at least 2/3
of ~150 tests, but more difficult to characterize than usual
since most tests use threading and perhaps consequently if
there's any problem, they simply freeze the overall test.) I'm
hoping that this can be substantially complete by the end of
the week; I certainly cannot wait until this happens because
perhaps the last thing I wanted to work on when I resumed
active development on Jython was SSL, but here I am doing it
There is of course other important work going on, as seen
in the commits and a number of outstanding pull requests, but
I believe our project consensus is that this is the one
blocker we have for beta 2.
Once this socket-reboot work is resolved, I believe we will
want to have one more beta, focused on performance/bug fixes.
This will include the following support:
- Bug triage, especially Windows bugs
- Regex improvements in the underlying SRE, likely using
the memoization proposed by Indra Talip https://bitbucket.org/indratalip/jython
- Use Jackson for our implementation of the json module
(Some of these could make beta 2, but they will not block
Related to this, a number of us have started a separate
project, jythontools (https://github.com/jythontools/
to capture integration points that in the past we would have
directly put into Jython itself, such as Clamp. Keeping such
work in the jythontools project helps decouple this work.
I can understand this is frustrating for our users who want
to have firm dates. The problem is that Jython 2.7.0
necessarily uses a feature-based schedule, vs a time-based
schedule (as seen in CPython, for example). Jython focuses on
compatibility with the Python language, as defined by the
CPython reference implementation; and usability as part of the
overall Python ecosystem, as now defined by PyPI and tooling
Subsequent releases of 2.7.1, etc., can instead use a
time-based schedule, as we move to working on performance,
better Java integration, and of course bug fixes. I certainly
cannot wait until we reach that milestone!