The dark Side of Python

Dream. Dare. Do – that is Suyati’s work principle in a nutshell.

May
17
2013
  • Author:
  • Nayab Naseer
  • Category:

pythonThe Python programming language has become very popular among developers within a short span of time. This object-oriented language, with built-in “dynamic semantics” and “data structures,” is now the preferred choice of developers for scripting, developing applications, and as a glue language to connect existing components together.

Python enhances the programmers’ productivity. It has a simple, easy to learn, and concise syntax, and comes with many open source libraries. Developers can concentrate on actually writing the program without worrying about the syntax. Python also supports modules and packages, thereby allowing code reuse. And finally, there is no compilation step, making the edit-test-debug cycle incredibly fast.

However, not everything is hunky-dory with Python. The popularity is for the Python 2.x versions. However, following Python 2.7, Python jumped to version 3, and this has opened up a Pandora’s box. Python version 3 was introduced in December 2008, and offered many improvements such as Unicode. However, five years later, most developers continue to use Python 2.7.

The main reason for persisting with Python 2.7 is the difficulties associated with making the switch to Python 3.x. The two streams: Python 2.x and 3.x, are different and are almost incompatible. Python 3.x also does not have the extensive library support that Python 2.x enjoys. Making a transition to Python 3.x makes little business sense, and as long as such reluctance continues, the program runs the risk of stagnation, and eventual obsolescence.

In addition to this incompatibility, Python has no options when it comes to runtimes. The only real Python runtime implementation is CPython, and this has significant limitations such as being incompatible with Java Virtual Machine. Python is also found wanting for memory intensive tasks, such as high graphics 3D games, or to write for kernel code. While the lack of compilation step makes things easy, this also means that there is no way to catch syntactic errors or mistyped variable names without actually running the code.

Leave a Comment

Your email address will not be published. Required fields are marked *