Quote:Original post by Daaark Also mention the ToonTown and Pirates Of the Caribbean MMORPGS, BitTorrent, and it's almost the standard scripting language for 2D and 3D Digital Content Creation Tools.
Not to mention the fact that Python is a very popular scripting language in game development. By no means did I intend for my list to be exhaustive. The things you and Washu mentioned should give the OP a pretty good idea of what can be done -- and what has already been done, and proven to work -- in Python.
The OP's problem is that the local variable 'input' has hidden the built-in function 'input' since they share the same name. Since 'input' now refers to a string, it cannot be called as a function. This should happen out of the interactive shell as well. Overloaded functions don't exist in Python, but it does support optional arguments and keyword arguments and since it's dynamically typed, a function may depend on the type of an argument.
Since variable can refer to functions, or to function-like objects, it's impossible, not to mention confusing, for variables and functions to have separate namespaces.
@alvaro: Well the function input() actually evaluates the input as Python code before returning it. For most things, using raw_input() is more appropriate. Why did that make you leave Python?
Quote:Original post by Windryder By no means did I intend for my list to be exhaustive. The things you and Washu mentioned should give the OP a pretty good idea of what can be done -- and what has already been done, and proven to work -- in Python.
Wasn't trying to step on your toes. :)
People always want AAA titles as references, even though it shouldn't really matter. Most big games are scripted with these types of languages anyways. It's the engine doing everything else.
Quote:Original post by alvaro I tried to learn a bit of python once. I gave up after I found out that `print input()' is powerful enough to evaluate 4*(1+2) as 12.
Quote:Original post by Ezbez @alvaro: Well the function input() actually evaluates the input as Python code before returning it. For most things, using raw_input() is more appropriate. Why did that make you leave Python?
Well, at the time I was looking for an alternative to Perl that would do fewer magic things for you. I was tired of having code that can mislead you completely as to what it does. Having `input()' actually evaluate an expression as code is sort of nuts. Why would the designer of the language think there was a need for that when `eval(raw_input())' does the same thing, in the rare case one someone might need that?
Quote:Original post by Ezbez @alvaro: Well the function input() actually evaluates the input as Python code before returning it. For most things, using raw_input() is more appropriate. Why did that make you leave Python?
Well, at the time I was looking for an alternative to Perl that would do fewer magic things for you. I was tired of having code that can mislead you completely as to what it does. Having `input()' actually evaluate an expression as code is sort of nuts. Why would the designer of the language think there was a need for that when `eval(raw_input())' does the same thing, in the rare case one someone might need that?
I agree with you on this edge-case. In my experience, Python tends to be more explicit than other languages and this side-effect of input() is bizarrely out of place in the language.
Quote:Original post by Ezbez @alvaro: Well the function input() actually evaluates the input as Python code before returning it. For most things, using raw_input() is more appropriate. Why did that make you leave Python?
Well, at the time I was looking for an alternative to Perl that would do fewer magic things for you. I was tired of having code that can mislead you completely as to what it does. Having `input()' actually evaluate an expression as code is sort of nuts. Why would the designer of the language think there was a need for that when `eval(raw_input())' does the same thing, in the rare case one someone might need that?
I agree with you on this edge-case. In my experience, Python tends to be more explicit than other languages and this side-effect of input() is bizarrely out of place in the language.
Perhaps I was too quick to judge the whole language on one unpleasant feature, then. I'll give it another try.
The one thing I don't like about Python is that the interpreter is not reentrant, and probably not thread-safe either. This can be a problem if you want to, say, update all game objects in the world in parallel, and the update operation involves Python scripts.
But I could be wrong about this. In fact, I am posting this in the hope that someone will tell me I'm wrong, because I would prefer Python over all other scripting languages I have seen so far, and the problem above might be a show stopper...
Quote:Original post by majickthise The one thing I don't like about Python is that the interpreter is not reentrant, and probably not thread-safe either. This can be a problem if you want to, say, update all game objects in the world in parallel, and the update operation involves Python scripts.
CPython suffers from the Global Interpreter Lock, which renders it extremely unfriendly to multi-threading. You can still use a multi-process architecture, or for the majority of tasks, asynchronous-I/O combined with fibers/coroutines.
And if your needs extend beyond that, you can go all the way to Stackless (a python implementation designed for concurrency), or tinypy (a python implementation designed for lightweight embedding).
Writing over "functions" (which are just variables like all other) may seem strange to C++, even more so when you overwrite it with a value of another type (string in your example), but it is very straight-forward and logical. Just free your mind from the low level pointers and bits of memory and look at the code from high level, see the beauty of it?
I reallly like Python. It is the first language I used for-each loops, functional programming and lambdas, generators and more.
Together with list comprehension, the interactive shell, pretty syntax for list slicing, and so many simple to use but powerful libs its really a terrific language.
A big "WOW" moment I remember was when a co-worker friend implemented Levenstein distance in python. This is an algorithm that given two strings finds how many chars are different between them (difference being deletion, insertion or modification). Next my friend wanted to implement Levenstein word-distance, that is an algo that given two sentences finds how many words differ. To our surprise, it was trivial! something along:
def word_levenstein(a, b): # split the sentences to list of words and then pass it to the regular levenstein algo! return levenstein(a.split(), b.split())
because strings were designed to have same interface as lists of chars, the code to find different chars found different words when given a list of words! To write a word-lev given a levenstein code in Java or C++ you would have to refactor the Levenstein code to use some confusing abstraction or re-write (copy-paste) the code. In python the abstraction was unintentional due to the great design of the language. WOW!
Smalltalk is like that too. String is a subclass of IndexedCollection, so it's just an array of Character objects.
That function in Smalltalk would look something like this:
wordLevensteinWith: a with: b "split the sentences to list of words and then pass it to the regular levenstein algo!" ^self levensteinWith: a asArrayOfSubstrings with: b asArrayOfSubstrings
