Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In Java, there are multiple languages that compile to Java bytecode and can run on the JVM -- Clojure, Groovy, and Scala being the main ones I can remember off the top of my head.

However, Python also turns into bytecode (.pyc files) before being run by the Python interpreter. I might just be ignorant, but why aren't there any other programming languages that compile to python bytecode?

Is it just because nobody bothered to, or is there some kind of inherent restriction or barrier in place that makes doing so difficult?

share|improve this question
18  
...because they don't want to deal with the GIL? ;) –  Mason Wheeler May 17 '12 at 0:04
4  
Instincts would tell me that it has a lot to do with just how mature the JVM is, well specified, and the JVM is on virtually all platforms or stupid easy to acquire. –  Rig May 17 '12 at 0:26
3  
I suspect also that most JVMs are much faster than python's interpreters. –  Peter Smith May 17 '12 at 3:32
11  
By targeting Java bytecode, you get all the features of a JVM (security, performance, portability, scalability, and so on). Targeting Python bytecode doesn't get you very much. –  David Schwartz May 17 '12 at 4:00
2  
Python bytecode is not recognised by later versions of the Python interpreter. How can anyone implement a programming language that compiles to Python bytecode? –  Gus Jul 21 '12 at 14:47

6 Answers 6

up vote 49 down vote accepted

Simple - last time I checked, Python had no formal specification, including its bytecode. CPython is the spec, and bytecode portability is IIRC not required. Thus, it's a moving, undocumented target designed for a specific language.

share|improve this answer
14  
In fact, the details of the bytecode format often change between minor versions, and even the 99% compatible PyPy doesn't even try (in fact, they add their own bytecode instructions). –  delnan May 17 '12 at 9:22

There are multiple JVM languages because there were talented people who wanted to write code that would work with existing Java code, but they didn't want to write Java.

Apparently there are no programmers who want to work with existing Python code, but hate Python enough to port another language to the Python bytecode interpreter.

You can look at this in two ways: there are alternative languages for the JVM because Java is so widespread, or there are no alternative languages for the Python bytecode interpreter because Python doesn't suck.

share|improve this answer
4  
+1 for python having a low coefficient of suck. –  Warren P Jun 14 '12 at 3:37
6  
I hope you are not implying that Java sucks or Java sucks more than Python :-) –  Giorgio Jul 21 '12 at 14:36
4  
@Giorgio: I'm implying that the creators of Groovy, Scala, Clojure, etc. thought there was considerable room for improvement. Are you implying that Python sucks? –  kevin cline Jul 22 '12 at 20:36
6  
After working with python I would say "low suck factor" would be inaccurate. It bucks too much commonly accepted stuff and that whole 'self' thing is extremely counterproductive. In fact dumb. How doesn't a class method know where it belongs? –  Rig Jul 23 '12 at 4:02
4  
I think it is a matter of VMs not languages. The JVM is a performant VM with a generational garbage collector, JIT, etc. While CPython uses reference counting and is an interpreter. It is CPython that sucks as a plataform. Btw hyhy exists. –  PuercoPop Jan 24 at 17:16

There are technical deficiencies such as the GIL in CPython, but few perceived language deficiencies, so the runtime isn't the selling point of the Python community. Exactly the opposite, there are more backend runtime options because of the dissatisfaction with the GIL/CPython implementation.

The Java Language is much more maligned than the JVM ( even in the Java community ).

The JVM is pretty well regarded in most circles; thus the desire for different/better language front ends with the benefits of the highly optimized back end JVM.

share|improve this answer

I say that Mason Wheeler is right. It's mostly an issue with the Global Interpreter Lock which makes concurrency a very thorny issue. Since there are other VMs that do concurrency really really well comparatively it makes sense to develop languages for those. Also Python has had a major language shift recently and many of the libraries have not caught up making compatibility a mild nightmare at times. For instance because I use PIL for vision work, I have to code in Python 2.7 or lower. This is not the case with the JVM or CLI setups which particularly in the latter's case were designed with language interop in mind.

Did some more research and apparently there are actually two GILs not just the one. The other controls Imports.

share|improve this answer
1  
"GIL free" is one of the technical reasons mentioned on "Reasons that CPython programmers might be interested in IronPython" in the Python wiki. –  Yannis Rizos May 17 '12 at 1:26
1  
@YannisRizos: Surely access to the .NET framework is not entirely inconsequential. Of course, it's possible that CPython users might be completely uninterested in that. –  Robert Harvey May 17 '12 at 5:27
    
@RobertHarvey Ninja edited that. Although I don't think of "access to fancy new toys" as a technical reason (not that the toys aren't great), the wiki also mentions that IronPython is easier to extend. –  Yannis Rizos May 17 '12 at 5:35

The earlier answers are all very good, but there is actually a language now that compiles to Python. From the GitHub project page:

Mochi is a dynamically typed programming language for functional programming and actor-style programming.

Its interpreter is written in Python3. The interpreter translates a program written in Mochi to Python3's AST / bytecode.

I know nothing about the language, but I'm assuming it generates Python ASTs and lets Python boil them down, avoiding the problems with actual bytecode that were already mentioned in other answers, so it's more like a transpiler.

share|improve this answer

Another reason is that the JVM is highly optimized, well-evolved, and extremely complete ecosystem. On it's own, it competes extremely well with any of the other compiled languages. (I won't say that it's the best general purpose VM out there, but I've certainly banked my career on that.) So getting access to the JVM, short of writing bytecode, is desirable in itself.

However, the Python VM is good, but (nothing against Python) has some serious shortcomings. The Python runtime environment suits the dynamic nature of the language well, but can really surprise you when you get familiar with its memory usage, global locking, or threading model.

In head-to-head comparisons, the JVM is typically twice as fast as the Python VM. The JVM (surprizingly) even competes well with natively compiled code, based on the "hot" optimizations it performs. And that's not even counting the more sophisticated thread handling, etc.

I love Python, I really do, and hate to say it, but sometimes the performance just kicks me in the teeth -- otherwise, why would critical Python libraries like numpy or scipy have to fall back into C code?

In other words, people who gravitate to Python do so because they like the language. But if you want to write a brand new language to suit your preferences, you're much better off compiling to the JVM, because your new idiosyncratic language will start off in one of the best (subjectively, maybe the best) operating environments available.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.