Python or Lua?

Started by
7 comments, last by Sneftel 19 years, 8 months ago
I'm thinking about implementing scripting in a game engine. I'm considering Python and Lua. Which one should I choose, and why? Any thoughts on the subject is appreciated. - Per Rasmussen.
Advertisement
I lean towards Python, because boost::python makes integration with C++ quite simple, as well as pickle (Python's serialization system). But I'm still experimenting myself, so YMMV.

Chris 'coldacid' Charabaruk – Programmer, game designer, writer | twitter

I'd reccomend lua unless you find you need the OOP features of Python. Lua is a smaller language that you can easily embed into an engine, and is quite powerful.
You can do oop with lua using luabind. I'd be interested in learn how to do the following in python though as it seems more naturally oo:

C++: Base class
EXPOSE: Base class to python
Python: Derive NewClass from Bass class
C++: Instantiate NewClass from C++
C++: Call NewClass overloaded methods from C++

I do this in lua/luabind thus but it's a tiny bit buggy!
<Fish>{
TonyFish: its not buggy anymore under the latest CVS build of luabind...it's an area the authors have been working on recently...I like their approach, too, its pretty simple.
No I meant my code in that thread is buggy (although it does what it's supposed to do)! I contacted the luabind people and will implement their suggestions tomorrow.

Nanight!
<Fish>{
I was cosidering these two (Lua and Python) also. In my opinion, Lua looks more elegant and is easier to use than Python. Anyway, it's not the point. Mostly I would like to know which one is faster (if term like 'fast' is correct in respect of scripting systems) ?

Thanks
___Quote:Know where basis goes, know where rest goes.
You could always look at the "computer language shootout:"

http://dada.perl.it/shootout/craps.html

Lua's pretty high on that list.
Quote:Original post by clapton
(if term like 'fast' is correct in respect of scripting systems) ?
It isn't, really. You should do processing-intensive stuff on the C-side, and expose an interface for it to the scripting side.

Programming language shootouts are stoopid for scripting languages, anyway. They emphasize number-crunching over real-world performance, meaning that the code that gets used isn't the same sort of code you'd actually be using.

Ultimately, decide on language features, not speed.

This topic is closed to new replies.

Advertisement