pyARS - from python to ARS

Why Python Is Your Friend

Do you have concerns using a scripting language?

Many people, especially those who used to develop C programs to talk to a Remedy server, confront us with their fears of slow or memory hungry programs. In this document, I’d like to give you a couple of reasons, why there is no need to fear Python :-).

So let me start by explaining, why we chose Python as preferred language. Throughout this document, please bear in mind, that we do not think, that one size fits all, or that Python is the hammer for every nail out there. Having said that, however, we have not yet found a problem in the ARSystem space that could not be solved this this hammer.

We came to Python from a very different angle, originally: We were searching for a document management system, found ` <http://www.plone.org>`_, which runs on ` <http://www.zope.org>`_ which is built in ` <http://www.python.org>`_. Exploring the python websites some more, we found many interesting projects and stumbled across many useful libraries and tools.

But what we found the most interesting things about Python, are the following:

  • For us, the most important aspect is, that you can write your scripts and applications in an interactive manner; using Python’s shell, you simply call one function (e.g. ARSystem API function), look at the result and continue your next step from there. This makes life so much easier than the traditional edit, compile, run, debug cycle. This is especially true for short scripts that you quickly develop during your daily life as a devloper or maintainer. Writing applications, we prefer a decent design over trial and error, but still, quickly trying something out in a very intuitive manner, is extremely helpful.
  • Writing programs in python is extremely productive (and fun, btw).
  • As the identation of the program code is part of the semantics, everybody needs to adhere to the same style guide. Which results in a highly readable code that anybody can read and understand, even months later.

Success Story

Let me give you one success story from real life: we had a C program monitor the status of the logged in users and update the information in a Remedy form every 20 mins. This program had been in use for a couple of years, the only complaint was that it would crash when you limited the search result.

When the company merged with another, user numbers exploded, and all of a sudden this C program would take forever to complete: a single run would take nearly 43 mins, and still it was run every 20 min.

The deeper analysis showed, that the runtime of the algorith would grow with the square of the number of registered users.

When we rewrote this program in python, we:

  • could reduce the algorithm very easily to be linear
  • could reduce the runtime from 43 mins to 30 secs
  • could reduce the code from 15 pages to 3 pages, making it much more readable and maintainable

I hear your questions: could you not have done this in C as well? Of course, you could have done it (at least addressing the first two bullet points above). But who has this hashing library hanging around that just comes naturally with Python? And then still, you would have needed all the glue code that makes reading the code so hard.

Speed

most often, people will ask us if the programs don’t run too slow? There are a couple of ways to answer this. - One possible answer goes like this: We are talking about

tools and applications that have something to do with an ARSystem server in the background that we want to talk to. Therefore, we have communication between our application and the ARSystem server, most often across a network. Thus, network latency, network bandwidth, network jitter and the ARSystem response time usually play a much bigger role in determining your perceived application performance than this little Python script on your computer. On top of that, the python interpreter compiles your script into a bytecode on the first run, that will be directly executed in following runs.
  • The other way to answer this question: Granted, you cannot compare the execution speed of python with that of C. You give a little bit in terms of execution speed, but you gain massively in term of developer productivity. However, if you have learned enough about Python, you can develop with speed in mind and use data structures and code fragments, that are directly implemented or mapped in C, resulting in C similar performance (e.g. list and list comprehension).
  • Yet another possible answer is, that speed concerns have been the main driver for us to connect python to the C API directly and not go through other layers in between.
  • Another possible answer is: use the power to develop your software quickly in python, optimize it, and if this still is not enough, resolve to e.g. C and code your module as an extension that you call from within python.
  • However you slice and dice this, there will always be people who bring this performance issue as an excuse not to try something new. There are enough pages on the web that deal with python and performance, that you can consult should you really need it. And always beware of pre-mature optimizations!

Other Questions

The following is a list of questions, we hear most often:

  • memory hug: of course, carrying your interpreter with you costs memory. But most memory is typically consumed when retrieving the ARSystem data structures from the server. So, are you freeing all this memory nicely?
  • executables: You do not need to deliver your source code to your client. There are tools available, that compile and link your code into a single executable that runs under Windows.
  • web frameworks: There are a couple of first class web frameworks out there that can help you build your own web application.
  • GUI applications: For any of the major GUI toolkits, there are python bindings available, e.g. GTK, QT, TK etc.

So we hope we could clarify why we don’t see any reason why you should be afraid of Python. But see for yourself and take a test ride. Have fun!