On 2011-01-18, Stefan Behnel <stefan...@behnel.de> wrote: > Tim Harig, 17.01.2011 20:41: >> One of the arguments for Python has always made is that you can optimize >> it by writing the most important parts in C. Perhaps that is a crutch >> that has held the communty back from seeking higher performance solutions >> in the language itself. > > The good news with Cython is that you no longer need to "write the most > important parts in C". Instead, you type them statically and compile them. > You don't even need to sacrifice Python source compatibility for that. So > you get the best of Python at the speed of C (or 'c', as some would say ;).
Well not quite. The fact that you still need a Python interpeter should tell you that the end result is not really just C. Effectively, you get the same thing that you might get from writing C modules for your performance sensitive loops. Cython just makes it a little easier to generate the C modules; but, there is still a lot of Python operating under the hood. >> I prefer a single language as opposed to a creolization of two. > > With the possible exception of Lisp, I find it hard to think of a language > that's still alive and not the creolisation of (at least) two other > languages. They all inherited from each other, sometimes right from the > start ("lessons learned") and always during their subsequent life time. I am not talking about language influences. Cython effectively requires two separate languages that interoperate. The end result is a mix of two code written in two separate langauges. That is not a single language solution. >> I certainly don't need to require anybody who >> wants to use a program I have compiled to install an interpreter. > > You will be happy to hear that you can link Cython programs against > libpython (even statically) to build an executable that embeds the > interpreter for you. Besides, on most operating systems, installing a Which means that you effectively end up with a py2exe style frozen binary. While that is a nice hack for solving some problems, it is hardly an elegant solution. It still effectively means that I have to package a redundant Python installation with every binary that I distribute. I just don't have to write installation routines that check for, and potentially install, a compatable version of Python. > interpreter for you. Besides, on most operating systems, installing a > dependency is done automatically, and Go code doesn't run natively on > Windows either, without first installing and running the compiler over it. Go works like C. If I compile my code on Windows, then I can give the binary to another Windows user and they can execute it without having to install any additional software (gcgo currently compiles everything using static binaries. Since the linker only includes the fuctions you actually use, you don't end up with the bloat of embedding entire libraries. I am not sure about gccgo.). The same holds true for Linux, BSD, OS X, and any other supported OS. Every go program includes a runtime componet that provides the garbage collection; but, all of that is included as 100% processor native code. That is quite a bit different from having to include an interpreter to run non-native code. -- http://mail.python.org/mailman/listinfo/python-list