Python Compiler - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Programming Languages & Scripting (/forum-8.html)
+--- Thread: Python Compiler (/thread-957.html)
Python Compiler - wyrmmage - Jul 26, 2009 01:08 PM
I've begun writing my first large-scale application in python, and I'm loving it After getting something up an running, I wanted to show it to the other members of the team, so I went about looking for a way to bundle my program, and I've run into a problem: python devs seem to not like compilers.
The first reason that I would like to compile my code is so that I can have other people just run an .exe or .app and have the program launch. The second reason is so that it's a bit harder for people to steal the code, since we'll be distributing this to the public after awhile.
Every time I see this question come up on the python mailing list, here's the general reply:
Quote:Why would you want to compile python? When interpreted, it can be faster than C, anyways.
Ok, I realize that python can, theoretically be made to run faster than C, but realistically it seems like a compiler would probably do a better job at optimizing the code than an on-the-fly interpreter. I'm particularly skeptical about this because I've heard the same argument provided for Java, and I know from experience that for that language, this claim just isn't true (yet).
and then the second half of the reply is along the lines of
Quote:You can't stop people from stealing your code, so why try? Just put a strong license on it and you'll be fine.
This is just wrong. If you distribute your source files and put a license on it that says no one may look at them, it's barely going to help at all. Besides, I know that I can't stop people from stealing my code, but I can control how quickly they can steal it If the person has to decompile my code back into python instead of just looking at its source, I eliminate a certain amount of would-be thefts. If the decompiled code has obfuscated variable names, more people are eliminated. If you can't decompile the program into python and instead have to start digging through the generated assembly code, you eliminate even more people.
Hmm. That reads a lot more like a rant than I meant it to. Anyway, I know some people that hang around here have made games in python, and I'm curious what you ended up using for your compiler (if anything). I'm compiling this for both Windows and Mac, so a cross-platform compiler would be nice, but I'm interested in hearing about strictly Mac stuff, too
So far I'm looking at shedskin, but it doesn't exactly look like a mature program.
Thanks in advance
Python Compiler - akb825 - Jul 26, 2009 02:31 PM
If you're looking for double-clickability, there are ways to set up your app bundle to do that. (and you can just have a script for other platforms like Windows or linux) As for compiling, it looks like there's the py_compile module to create byte code. It looks like it still goes through the interpreter, though, so don't expect a large speed boost.
Python Compiler - stevejohnson - Jul 27, 2009 08:04 AM
wyrmmage Wrote:The first reason that I would like to compile my code is so that I can have other people just run an .exe or .app and have the program launch.You don't need a compiler for that. Use py2app and py2exe.
Quote:The second reason is so that it's a bit harder for people to steal the code, since we'll be distributing this to the public after awhile.You can strip out the .py files and just use the .pyc files. They're pure bytecode. You'll have to keep around one or two .py files to start the program up, though. No matter what you do, someone will always be able to copy those files out, wrap them in a module, import them from the REPL, and peek at your functions' arguments, docstrings, behaviors, etc. It is completely impossible to prevent people from doing this.
The main barrier to writing a Python compiler is the extreme dynamic nature of the language. It's very hard (in some cases impossible) to calculate parts of a program's behavior at compile time that would have been calculable for a more static language. Memory allocation is particularly tricky because you can add arbitrary attributes to a class at any time. You can also monkey-patch other people's functions with your own.
However, Google is working on the problem. The Unladen Swallow compiler targets LLVM, which targets everything. It's already faster than Python is with the psyco JIT compiler. I would estimate that it's still a year or two away, but the current progress is pretty impressive.
One last note: please drop this 'compiled vs. interpreted' notion. It's much fuzzier than you might think.
Python Compiler - wyrmmage - Jul 30, 2009 10:14 PM
Thanks for the replies
I'll check out the links provided.
diordina Wrote:No matter what you do, someone will always be able to copy those files out, wrap them in a module, import them from the REPL, and peek at your functions' arguments, docstrings, behaviors, etc. It is completely impossible to prevent people from doing this.
This seems weird. I could write a script to operate on my .py files that removes docstrings and obfuscates the variable names....it seems like it would be even easier to include an option to do this when turning .py files into their .pyc equivalents.