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 nonblocking SSL.
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 it.)
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 like pip.
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!