You read it right. It's all about implementation. Today, we will talk about the different implementations of Python. A heads up on the different kinds, be it Cpython, Brython, you name it. This in conjunction with their main advantages, in essence, option A vs option B. I you have been in the game for a while, I'm sure you've heard a name or two pop up. Let's dive in a little deeper.
First thing's first, though, a note
A language is one thing, implementation is another.
Basically what this means is that an egg and a cake are not the same things. One comes from the other.
Python as a language is interpreted, the implementation, however, is why we have this article.
CPython
The C implementation of python. The de facto implementation I'm certain you have and it's CPython and not Cython which is something totally different. You see, when you run a simple python script to print say Hello world, this is what happens in the background; the program is compiled to bytecode and interpreted. The compilation creates a *.pyc file, short for 'python compiled' file you might put it. You will not see this file though, as it is deleted when the program exits. In larger projects, however, you might notice the here and there *.pyc files. In this case, the project in question, once run again, will use the pyc file, which is obviously much faster as there is no need to compile it first then run it, instead.
As a somewhat different implementation of CPython, we have CrossTwine Linker. It would be a disservice if I had not mentioned this under CPython. By default, Python is slow the larger, say the project. This attributed to dynamic typing(not having to define the type of variable upon initialization). Here is where CrossTwine comes in. Giving Python a little juice. How it does this exactly, is by packaging CPython with their own add-on libraries, these, of course, being hidden from public view.
Note the comparison on the speeds in runtime. Lower, of course, being better. Ohh, what power!
Wow! So why have I not heard about it? Ummm... Perhaps because it's commercial? You have to pay for usage. You can, of course, absolutely go for its full details in CrossTwine's page. If you thought it was all fine with speed, then woosh, are you in for a disruption.
Brython
Ever wanted to skip writing Javascript on the client-side? Full disclosure, I have. Context switching sometimes catches up. Sneaky little thing. Brython, allows you to write python code directly onto the browser. As a hello world example:
# create a pop up with information fed into the HTML5 input field
from browser import document, alert
def echo(ev):
alert("Hello {} !".format(document["zone"].value))
document["test"].bind("click", echo)
For a list of some talks, events, and so on or even jumpstarts on Brython, you might take a look at their wiki.
IronPython
The same python, with C# implementation, letting you run your code on the Microsoft Common Language.
So why us IronPython? My take would be, among other things, avoiding the Global Interpreter Lock. In short, GIL prevents your normal python installation from fully doing multiprocessing. Forget about the under the hood bury your head in the sand multithreading. In this case, we are talking about taking full advantage of different processors working on different things at the same time. It allows multi-threaded code to use multi-core processors. Hold on a minute before you go here though, you might want to take a look at the previous talk, If you don't know about it, you don't need it. If you are a .NET kind of person, this would be your GoTo. Integrate the two together and make some good worthwhile soup. Definitely worth the effort. Where to start? Why not their official page?
Jython
The fuss of the month, Jython. The Java implementation of python meant to be complementary to, you guessed it Java. Repeat after me and say complementary! Do not go there one-sided. Just like IronPython, it allows you to embed scripting, in this case to Java systems, making it possible to play with your java program in almost a similar way as the interactive python shell. So you can use Java in python code or vise versa. Your python code will produce Java bytecode, which will, in turn, run on a JVM(Java Virtual Machine). I assume we all know how Java bytecode, once compiled, is portable across a magnitude of devices already having this support.
PyPy
I thought I'd just start off with a mild comparison of PyPy with CPython.
Now, here is where we talk about machine code; the reason why C has remained the big man in the playground. It all comes down to this. You see, unlike Java's bytecode, for instance, C will compile to machine code, the direct language of the CPU. So there are no intermediaries. It's a boom and clap.
A simple analogy would be saying machine code is your operating system, while bytecode is an operating system installed on a virtual machine. One one side, you have something that is directly in contact with your PC, while on the other, you have a slight layer before the actual machine hardware.
This speed is the reason why a lot of data libraries, for instance, SciPy or NumPy are written in C.
Call PyPy a cheat sheet. So, if, for instance, you have two python modules and one of them gets imported a lot to be used somewhere else, PyPy will take note of it, turn it to machine code and cache this, so that next time you import it, you are no longer dealing with the code on top-level per se, rather telling the CPU: "remember that thing we did?"
Just how fast are we talking about? You can see on the PyPy site how their carefully crafted example, a similar program written in C and PyPy, PyPy beat C by 50%! A whole 50% faster than C for this use-case!
If only wishes were horses though. Despite its low memory usage, speed, and the micro-threading, PyPy has its weaknesses. For one, it's implemented in Python(weird, I know). This means that while CPython enjoys the ocean of modules written in C, PyPy sits on the sidelines. An example, PyGame.
So while you might find Django to be lightning-fast in some instances when using PyPy, database management might be the opposite, as most of the database libraries were written in C. A little bit of patience is needed here. We simply cannot have it all!
There are numerous other python implementations, but these top the list. So go forth and choose wisely!
That's it for now. Reach out in the comment section as to which you'd go for. till next time; TheGreenCodes.
Oh, and you can get us on our twitter handle: TheGreenCodes.
Top comments (0)