[fijal]

So well, one interesting question as to why this is at the top of hackernews is - do people not know about jython? Jython does exactly that - it compiles python into java (I think it emits bytecode and not Java source, but don't call me on that) with a lot of runtime so it can support proper semantics. It has been around for over a decade now too and it supports full python (with usual caveats)

[jestar_jokin]

Jython is quite outdated and has stagnated for a long time; support for Python 2.7 was only finalised in May this year. Forget about support for v3.5.

Perhaps by compiling from the bytecode of the existing interpreter, instead writing a whole new source code interpreter for the JVM, it will have some benefits in supporting newer versions of the language. Or, maybe it will help to decouple development of the standard library and the interpreter, possibly letting more devs work on it. You can't really be sure what benefits/deficiencies a different approach will bring until you actually try it - see PyPy, a "silly" idea to implement Python in Python, which now yields faster runtime performance than CPython.

[techdragon]

This is exactly why I spent a few hours trying to work out if I could perform some advanced trickery to plumb the pypy tool chain into something that would end up producing a pypy.jar or other JVM equivalent. Turns out it's not that easy. C to JVM isn't a well trodden path.

Jython is awesome and all but its fighting an uphill war against rapid progress in 3 with far too few resources.

[pjmlp]

> C to JVM isn't a well trodden path.

But it does exist.

https://wiki.openjdk.java.net/display/Graal/Publications+and...

Check "Truffle C: Dynamic Execution of C on the Java Virtual Machine."

[fijal]

That is the usual "what's easier - starting from scratch or updating existing codebase to newer python". Obviously starting from scratch is more fun, but finishing it to support full python will be a major task that will probably not happen.

PS. Jython also would be called transpiler in modern lingo

[brudgers]

One reason might be a development environment preference since developing directly in Jython would typically imply the overhead of the JVM. Another possible use case may be porting where a transpiler could address differences between implementations automatically that would otherwise have to be addressed more manually at the source code level.

To put it another way, Jython makes obvious sense when the primary target is the JVM and there's little legacy code. As target platforms proliferate and the code base becomes cruftier, it may become a less obvious choice.

I'm not sure the Pythonic "only one way" extends quite so far as to make Jython worthy of monopoly status.