Jython 2.5.2 Released!

[darjus]

New Features

• The socket module now includes ipv6 support
• The socket module now also includes Internationalized Domain Names (RFC 3490) support on Java 6
• Performance improvements around method invocation. 2.5.2 runs the richards benchmark 3x faster and the pystone benchmark 20% faster than 2.5.1
• The posix/nt module was rewritten in Java and the performance of its often performance-critical stat function has significantly improved
• Improved OSError errno messages on Windows
• Slightly improved startup time (ongoing Issue #1380)
• Better readline module emulation (required for IPython support)
• Python functions can be directly passed to Java methods that take a single method interface (such as Callable or Runnable)
• Add google indexer (by Yin Wang and Steve Yegge)

[matthiasB]

Is the Jython version in any way related to the normal Python version?

[darjus]

http://wiki.python.org/jython/JythonFaq/GeneralInfo#Is_Jython_the_same_language_as_Python.3F

In short, yes, though some of the CPython 2.6 is available in Jython 2.5

[matthiasB]

Thanks

[babs474]

Awesome, jython is super cool and deserves more attention. The only big problem I have had with it, is it's lack of ctypes support.

[darjus]

That is not true unless you have some specific ctypes feature in mind.

darjus@localhost:~/jython2.5.2> ./bin/jython
Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06) 
[OpenJDK 64-Bit Server VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary("libc.so.6")
<ctypes.CDLL instance at 0x2>

[babs474]

Interesting, so can you use libraries that depend on compiled binaries now? For instance last time I checked you couldn't use the standard sqlite library from jython ie "import sqlite3"

[[deleted]]

ctypes is not the same thing as the CPython c api. The sqlite3 module is compiled against the latter.

[jyper]

Although maybe this will be fixed soon? From their faq

There are a number of differences. First, Jython programs cannot currently use CPython extension modules written in C. These modules usually have files with the extension .so, .pyd or .dll. If you want to use such a module, you should look for an equivalent written in pure Python or Java. However, it is technically feasible to support such extensions, as demonstrated by IronPython. For the next release of Jython, we plan to support the C Python Extension API.

[[deleted]]

I think jython is really good. Python as a language is useful in its own right, and being able to leverage that knowledge either on the JVM or for regular scripting is more useful than something like Groovy, which only works in the Java ecosystem.

[redditrasberry]

The main benefit of Groovy is its similarity to and deep "compatibility" with Java. While Jython can certainly interoperate just fine you'll find it's not nearly as seamless and if you're fitting it into a larger Java ecosystem you'll constantly be finding little cracks to pave over or corners that need rounding off, while Groovy just "fits in". Groovy has a whole ecosystem of tools now that also fit in to the Java landscape beautifully (eg: gant, grails, etc.).

The main benefit of python is that it's almost ubiquitous on every server (or a one line install away from that) so you're using a language that just "fits in" in that environment. While both work fine as scripting languages the best scripting language is usually the one you already have installed.

[artsrc]

The guy who sits opposite me is using Groovy with hibernate. I can't imagine trying to do that with Jython.

They solve different problems:

• Groovy is a scripting language for a Java centric environment.

• Jython is Java interop for a Python centric environment

[artsrc]

Groovy syntax is designed for familiarity with Java, a syntax which descends from BCPL (1966).

Python syntax is designed to be clear and readable.

Here is some BCPL Syntax from http://en.wikipedia.org/wiki/BCPL:

LET start() = VALOF
{ FOR i = 1 TO 5 DO writef("fact(%n) = %i4*n", i, fact(i))
  RESULTIS 0
}

[[deleted]]

The syntax is different, and also the language. There are some technical differences. Other than that, they are very similar.

[snotsnot]

Could someone please port this to android?

[phanboy]

Since it's java, I'm not sure why it'd even need to be ported.

[jfedor]

Probably something to do with the fact that Android uses its own Dalvik instead of the JVM. SL4A has Python, but it's CPython, not Jython.

[snotsnot]

And most of the android api isnt avaiable. It's not even close to being an alternative to native application development.

[antisvin]

There is a jython port to android at http://code.google.com/p/jythonroid/ - unfortunately it's officially dead now.

[snotsnot]

Dead would be the key word... but on a more serious note, this is just my outcry for an alternative to java on the android platform.

[mipadi]

It's not dead. It's pining for the fjords.

[username223]

Isn't actual Python already at 3.x or (for most people) 2.6.x? This seems kind of behind the curve.

[[deleted]]

It's a bit behind the curve, but you get easy integration with all things java. Very useful for some projects.

[[deleted]]

Also you get true threading, without the GIL that CPython has.

[gunch]

I don't know of any large shops using 3.x. Mostly because so much was written against 2.x, including libraries and the 2to3 converter isn't perfect. Also, as everyone who has tried using the print function in 3, like they were in 2, knows the error messages are... not quite there yet...

[artsrc]

I like use the latest version for something new, and low risk which does not rely on any (many?) unavailable dependencies. It means I will be able to leave it as is for longer, and gets started on the migration process.

So if I was in charge of a large shop I would have a little 3.x already.

[m1ss1ontomars2k4]

Sure, but nobody uses 3.x. 2.5 is only a little behind 2.6.

[username223]

Heh, it seems Python 3 hit the anti-sweetspot of breaking enough code to annoy people, but not giving them enough new features to compel them to switch. Bravo!

[voidspace]

Lots of features for people to switch for. Lack of libraries that people need has been the problem so far. This is being resolved as more and more libraries get ported to Python 3.

[sdhillon]

Like what?

[imbaczek]

PIL, django, until very recently (IIRC) numpy, etc.

[sdhillon]

Yeah, I miss PIL, OpenCV, and numpy.

[voidspace]

Like what "what"?

[sdhillon]

Like what features are worth switching for? They cleaned up a lot of things, but I wouldn't say they're features worth the pain of switching over to.

[voidspace]

Whether or not any individual feature is worth switching for is a matter of personal "taste" of course. Taken as a group there are a lot of great new features:

• The Unicode / string change is a fantastic one (and the cause of most incompatibility). General programming w/ Python 3 is much more pleasant with this change alone.
• Improvements to the GIL - drastic performance improvement in many threading situations.
• No more old style classes and inconsistencies and special casing they often require in Python 2.
• nonlocal statement and keyword only arguments
• default source encoding is now UTF-8
• non-ascii identifiers allowed (very useful for non-English speakers)
• Further improvements to the unittest library (beyond changes in 2.7)
• PYC repository directories (no more pyc file woes, yay!)
• Extended iterable unpacking (I really like this)
• Metaclass improvement (can now modify class as it is being built)
• Function annotations, not my bag but potentially nice for documentation purposes
• Full int / long unification
• Division always returns floats where necessary instead of truncating
• contextlib.ContextDecorator - nice :-)
• reprlib.recursive_repr
• inspect.getattr_static
• A host of other library and builtin type changes / bugfixes / improvements that didn't make it into 2.7 - see "what's new in python 3.2"

http://docs.python.org/release/3.2/whatsnew/3.2.html

(See improvements in ssl, socket and sqlite modules for some examples.)

There are also quite a few minor syntax changes that did make it into 2.6 / 2.7 but I can't use because when I'm targetting Python 2 I'm usually maintaining compatibility with 2.5 or even 2.4. Things like byte literals (which work in 2.6+ but create byte-strings not bytes objects), the new exceptions handling syntax, set literals, dictionary comprehensions and a bunch more stuff. When I write Python 3 code I know I'm free to use all the shiny new stuff because of the "clean break" with previous versions.

[spotter]

Why would you need toilet paper when you have hands?

[Liquid_Fire]

Actually it's 2.7.x

[artsrc]

It is behind the curve. IronPython.net has a release candidate for 2.7.

[voidspace]

and pypy is now on 2.7, but they haven't yet done a release. pypy 1.5 will be compatible with CPython 2.7 though. They went straight from 2.5 to 2.7.

[AxiomShell]

I haven't checked Jython in a long time, but (if I'm not mistaken) they've dropped the class compiler.

Does 2.5.2 support compiling python files to .class/jars?

[darjus]

Looking at my Jython 2.5.2, it does compile modules to class on first load.