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
13  
...because they don't want to deal with the GIL? ;) –  Mason Wheeler May 17 '12 at 0:04
3  
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
2  
I suspect also that most JVMs are much faster than python's interpreters. –  Peter Smith May 17 '12 at 3:32
8  
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
1  
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
add comment

4 Answers 4

up vote 34 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
11  
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
add comment

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
3  
+1 for python having a low coefficient of suck. –  Warren P Jun 14 '12 at 3:37
5  
I hope you are not implying that Java sucks or Java sucks more than Python :-) –  Giorgio Jul 21 '12 at 14:36
    
@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
2  
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
1  
@Rig Personally, I think Python's approach is more elegant. The OO follows organically from the syntax rather than requiring a special keyword that looks like a variable. As to why class methods don't know where they are, it's because Python class definitions are just code, and this code isn't privledged because it happens to be located inside a class definition. You can define methods anywhere and add them to a class at runtime. In fact, you can take the same function and use it as a method in multiple classes, something that wouldn't really work with the this paradigm. –  Antimony Jun 6 '13 at 6:23
show 5 more comments

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
    
@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
add comment

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 VM ( even in the Java community ), thus the desire for different/better language front ends but the benefits of the backend VM.

share|improve this answer
add comment

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.