http://lua-users.org/wiki/LuaVersusPython
Lua Versus Python
Introduction
Python [1] is a popular scripting language. Both Python and Lua are commonly embedded in applications to provide scripting support.
Scripting is more frequently being used in games. There are many factors to take into account when choosing a scripting language. It may be a simple decision based on the architecture of the target platform like whether you are on a PC or game console. Assuming you have the luxury of a fast CPU, virtual memory, and hard disk storage, the vast library resources of Python could help get your project completed sooner. If you don't have those luxuries, Python is not an option as it is quite large.
Comparison
The following is a simple comparison with pros (+) and cons (-) listed.
Python
(+) Is better equipped. Huge library of very useful functionality. Very useful for off line work, e.g. tool scripting. Huge catalog of example scripts [2], tutorials [3], help [4] and general reference material [5].
(+) Extremely high performance numeric computing (ala scientific and graphics) is possible with an add-on module that implements true multidimensional arrays. Strictly speaking, Lua has no arrays and must use a table structure for them. Lua arrays are tables, that's true. The implementation has dual nature, however, and array usage (1..N indices) is optimized as it should be. -ak
(+) ctypes (a module available for Python 2.4 and scheduled for core inclusion in 2.5) allows access to existing shared libraries (.so or .dll) without writing a C wrapper.
(+) Has a remote debugger [6].
* There does appear to be a debugger for Lua which has a remote target addon, see Titmouse on LuaAddons. Has anyone used the remote debugging functionality that could comment? —NDT (wxLua5 has it?)
(+) Python has a nice simple syntax and behaves "as you would expect". ie. no gotchas for scripters like undeclared local variables default to global. Note: this is being resolved in Lua with the new -w flag "(Lua 5.1, but it could be done before, using metamethods)". Python is potentially easier to script for inexperienced scripters/game designers. Really, is it? -ak Yes, it is. I find myself and others having to explain lua quirks to game scripters. python's syntax is more natural (yes, even including the indentation) -DanHollis?
(+) Python has extensive slicing for strings and lists, which is a big productivity gain. I would recommend a slicing library be used by those who want to be more productive in Lua.
(+) Python has more extensive (though by no means perfect) Unicode support.
(+) Python has built-in support for object-oriented programming (in Lua, you need to build your own)
(-) Numerous modules including binary DLL's with the standard distribution make it difficult to bundle python with other programs; it may be difficult to modify and specialize if it is not exactly what you require.
(-) Python is whitespace sensitive. While this has its upsides, this can be awful if you happen to be editing the script with some sort of embedded property page that converts tabs to spaces or doesn't accept entered tabs when the source is formatted with them. When using a proportional width font, indentation may become much narrower and more difficult to see (and official python sources tend to mandate use of space).
(-) Python does not support multiple threads with multiple interpreters in a single process. Multiple threads can access the Python interpreter but each thread must hold a global lock while doing so. This is incorrect. The global interpreter lock" is per-interpreter as its name implies, not per process; you could indeed imbed multiple interpreters in a single process. -JonathanEllis? The original author is correct, the GIL is per process. You can have multiple interpreters, but they're just a scoping thing, they do not allow multiple concurrent threads to run. See [7] for the most concise discussion I've found on this.
Lua
(+) Smaller footprint than Python. e.g. Look at the size of python22.dll, 824kb. A basic Lua engine, including parser/compiler/interpreter, but excluding standard libraries, weighs in at under 100kb.
(+) Uses less memory [8]
(+) Faster interpreter (Lua vs. Python) and faster JIT compiler (LuaJIT vs. Psyco) [9].
(+) Has a nice simple API for talking between script and C, with very little generation of glue code required. Try creating and manipulating lists and dictionaries in Python and then doing it in Lua.
(+) Doesn't use reference counting for objects which can get complex and error prone. Although you can use things like the Python Boost library [10] if you're into C++.
(+) Lua started off as a configuration language. This has some nice quirks in that it's great for creating and configuring things - which is what you want to do in a game. Python is probably ahead if you want to write big complicated apps because Lua has some issues, but then Lua is catching up (e.g. table syntax, anonymous functions).
(+) Has a nice, simple, and very powerful syntax. I find you can write the same thing in Lua with less code than Python and you have more flexibilty because of Lua's metamechanisms. e.g. tables are lists and dictionaries combined in Lua (although you can make them behave like PythonLists and PythonDictionaries). Anonymous functions are also particularly nice for configuring things. In Python you get their poor cousin, lambda functions.
(+) Small, simple, stable codebase. Easy to poke around inside and modify if need be. Probably not as well documented and commented as Python.
(+) Lua does support multiple threading. Multiple Lua intrepreters can exist in the same process and each one can run independently in its own thread. Thus Lua is more suitable for embedding in multithreaded programs.
(+) Lua does not dictate any particular OO system. Instead you can build your own (using meta-methods) and tailor it to your needs.
(!) There is still a lack of introductory material for Lua. I think the wiki should probably contain something like the Python tutorial [3]. Ok, see LuaTutorial.
(-) Programs are much more error prone, due to automatic coercion, accessing of unset variables without an exception, and having to check most functions for nil values, rather than just catching the exceptions. There may be some advantages to some of these points however.
IMO the only decent way of solving this is static analysis. Most of my catastrophic globals typos have been in less-used codepaths, and even had -w survived, they would have blown up on people at the worst times. Hence LuaLint, which I suppose I should have a go at for 5.1… — JayCarlson
(-) Lua handles only one type of numbers, usually C doubles or floats, which can lead to overwhelming processing. You should look at the work Python does to add two integers, and think about what overwhelming processing might mean. (In Python, every integer outside of the range [-1, 100) is freshly allocated, for example.) Lua number type can easily be changed at compile time to double, float, even long or int (if one doesn't care for floating points..). But there is a genuine need to have separate int and number types, I agree. -ak
(-) Lack of built-in binary operators (or, and, xor, ..). Embedded systems would really benefit from these (can be made as addon libraries, or using LuaX enumerations).
(-/+?) Lua starts table indices at 1, which is strange for a language designed to interface with C where arrays start at 0. (Comment: Ad-hoc , there is no problem to use index 0 or even -1 … So if you are a C programmer, you can use "t[0]=t[-1]" etc. But if you are not programmer… for example math-scientisct you can feel familiar with tables t[1..n] )
On the fence
* They both have automatic binding generators. SWIG works for both. Lua also has toLua (which hasnt been developed for a while but works for 4.0 - not sure about 4.1). Update: There is now a toLua 5.0a, which works great!
References
* Crystal Space [11] supports both languages. The source code available may provide useful information to help decide on suitability. Update: lua may be stagnant due to lack of swig
* The Nebula Device [12] also supports both languages in addition to TCL.
User opinion
Please let's not start a flamewar here. Please feel free to make a simple objective statement about your experience.
* IMHO I've dabbled with putting both in games and tools. Python is better for offline tools, Lua is better for embedding and configuration. Python has a mass of very useful libraries for most tasks and Lua is small, fast and very configurable, ideal for embedding. — NickTrout
* Everything is an object allocated on the heap in Python, including numbers. (So 123+456 creates a new heap object). I think this might be a big part of the speed difference. —JeffPetkau
* Lua 5.0 has excellent coroutine (or latent function or whatever you call it) support, which is very important for game scripting. Stackless Python had them too, but they never made it into the core. (This was *the* issue that decided us on Lua over Python in our engine.) —JeffPetkau
A strange point to base your entire decision upon. Python's generators are the same as the upcoming Lua's limited coroutines. See LuaList:2002-07/msg00174.html.
They're related, but not the same. Lua's coroutines are much more general. Also, we didn't base the entire decision upon this point; it was just the issue that tipped the balance.
Python generators historically were not "the same" as coroutines: see http://www.python.org/dev/peps/pep-0342/ for recent changes to Python to support coroutines.
But does that really help with recursive generators? See LuaCoroutinesVersusPythonGenerators
* Lua is ideal when you want a small footprint being added to your code: it's the smaller scripting engine available at the moment, afaik. That was because I have chosen it to develop Lixoo, a 2D adventure game engine. One of my goals is that a ready-to-use Lixoo distribution (including the engine and basic development tools) must weight less than one megabyte. — AdrianPerez
* Lua has the power of Lisp/Scheme, but a simple syntax and also a great implementation. I am very interested in how Lua performs in embedded (real-time) applications. Its core is small, its design allows for flexibility. Special language features, such as state-depend sets of methods in an object, can easily be implemented through metatables. State can also be kept in coroutines. Those are all things which I had wished to have in Python. However Python shines with its plentiful libraries, its excellent documentation and its beautiful syntax. I do not like it to close every block with an "end" I am not used to it anymore ;-) Last but not least some bugs cause exceptions in Python like division by zero, regardless of the number type (double/integer), whereas I think Lua catches more errors during compilation. However I assume Python will catch up. Tools like PyChecker? are already available and some ideas will be hopefully integrated into the core. I like both languages and use them for different purposes. — Dominic
* I have been, and still am, an avid Python user. I have never used Python in an embedding scenario, however, because I found it to be too painful to work with. When I encountered Lua 3.2, I felt like someone had opened up my skull, found all my criticisms of Python's embedding and then used that to make a language and environment that did what I wanted it to.
Since then I have continued to use Python, of course. I find Pythonbecause of its huge set of librariesto be a more suited to general-purpose scripting and RAD work. I'm also very comfortable with Python's syntax, quirks and all, so find that my fingers just naturally do things The Python Way. (The number of times I've been burned by using '.' instead of ':' as a method accessor in Lua would make most people choke with laughter.) I laugh, however, at even a hint of the slightest possibility of using Python for anything embedded. Lua is my tool of choice there. — MichaelRichter
* The Pythonic way is to extend rather than embed. Embedding is regarded as something which should never be done, in the Python community. ( For a brief explanation of why, see http://www.twistedmatrix.com/users/glyph/rant/extendit.html .) Lua fills the niche which Python avoids here quite neatly. On the other hand I think some nice dynamic library support in Lua wouldn't go astray. (I'm the author of that rant, and I don't think that it necessarily reflects the mainstream view of the Python community. I wish it did - I really do think most embedding just plays to the insecurities and misconceptions of C programmers rather than filling a real technical need. On a related note, I have been waiting for Lua to realize it's a real programming language and stop messing around with this "script" garbage…)
* I use Python extensively for game development and I think that Lua may be a better choice if you are looking for a language you can easily embbed into your engine to create entity logic or configuration/tweaking scripts. Python is a powerful general-purpouse language and you will pay a price for that in terms of integration complexity, performance and memory requirement. If, however, you are shopping for a high productivity language that can replace C or C++ in many of your modules, Python is clearly a better choice (as noted above, this is better done in Python through extensions instead of embedding). Lua was desinged for small scale scripts and can't compete with Python for large scale development. — Camelo
* New to scripting, I intended to compare different alternatives before settling on a one to use in my 3D game engine. I spent three hours getting basic Lua 5 embedding and extending to work. I though to myself, "this scripting thing isn't that hard!", and turned to Python. Four days of pain and frustration later, after having miserated with the Python C-API, trying to get Boost.Python to compile with Python 2.3, trying CXX and SWIG and God knows what else, and trying to get these to run using windows.h under Visual Studio 6 (which caused multiple mutual incompatabilities) I found luabind and I don't think I'll ever look back to Python again. — Mike
o Just a comment for Mike : although I never used it, Boost.Python does not work with Python 2.3 but 2.2. See [13]. — Thomas
+ I'm not sure when this reference was made, however you can easily switch the version of Python Boost.Python compiles against, currently. However, Python is a somewhat pain to embed, I've found. Most notably, it's Global Interpreter Lock mechanism is a bit of a pain for multithreaded C++ apps.
+ Boost.Python 1.33.1 news: build now assumes Python 2.4 by default, rather than 2.2. — AnonymousDonor
* Python's scoping, even with the "new" nested scoping, is very limited and error-prone. Loops and such constructs do not open a new scope, so there is no way to create private variables within them. This is a problem, for example, if you happen to make a variable in your loop that has the same name as something preceeding the loop: you will overwrite that outer variable. There is no way around this in Python other than to be wary of name clashes, or to use lots of nested functions in order open new scopes. In contrast, Lua gives you precise control in this situation: within the loop you can either use local and make a private variable, or omit it and write to the outer variable. —JohnBelmonte
o In my experience, hiding a variable from an outer scope is what is error-prone, and Python prevents this. A single name within a single function referring to two separate objects is bound to confuse people. In fact, many C++ style guides advice against hiding variables like this. Python emphasizes readable code, and disallowing this behaviour you want is actually a step in that direction. —AnonymousDonor
o In C#, hiding variables that way is an error. I like it that way - I want the compiler to notify me of any ambiguities, and let me disambiguate them (by making variable names unique within a function) — BjarkeDahlEbert
* I'm new in the both languages, but I would say that both languages seem as powerful, but they don't do the same job. I would say that the difference between python and lua is the same as the difference between java and C. Like java, python is big, with large libraries, quite slow, but works well to use a lot of functionalities. On the other side, like C, lua is light, implemented on nearly all platforms, but helps the user less to have a good design. —Xavier
* I spent a good amount time researching a scripting language to embed in a C++ program and it all came down to Python or Lua. After spending more than a day trying to get boost.python to work, I gave up since I couldn't even get a trivial Hello World program to compile with bjam. On top of that I didn't find a decent way to just add in some global variables (that were pointers to C++ classes) to a python interpreter and didn't like the boost.python syntax or methods for implementing virtual functions. Anyways, I decided to spend a few hours and see how far I could get with lua and using tolua++ I able to expose all public methods and vars in dozens of classes and everything worked as I expected. Yea, the virtual function implementation doesn't work and I can't derive from a C++ interface to create a new lua class, but I'll live. Neither are a complete solution, but anything is better than implementing all this in C++. —Tom
* Just a quick point to all those who struggled with SWIG or Boost etc with Python — I found PyInline [14], it's like magic. I just make a string with some C code, call "make", and I have callable Python routines! It works great on XP and Fedora, with the exact same source code. Some quirks regarding includes, but for simple gluing to a .so or DLL, it's killer. That said, I'm on the prowl for a super-small core embeddable language for some robotics stuff, and Lua looks very nice so far.
* Those complaining about the hazardous nature of the Python-C API should look at Pyrex. I haven't worked with it myself but I think I'll end up doing that for my upcoming game. It has Pythonic syntax but can use C datatypes, and thus you can much more easily write C modules for Python. Of course, this is still extending Python rather than embedding it. I might use Lua instead if I find out that I'm not using a lot of the added functionality or stability of Python.
* For Python, use Elmer. http://elmer.sourceforge.net/ . It really makes embedding and extending Python easy.
See Also
* LuaComparison - how Lua compares to other languages
FindPage · RecentChanges · preferences
edit · history
Last edited July 21, 2007 3:44 pm GMT (diff)
