Why I learned (some) Python over a weekend

I have to be honest: new tools can scare me as a developer. In a world where new languages, frameworks or techniques for software come out daily, it can be difficult to decide when to switch and when to stick to your comfort zone.

I dealt with this question few weeks ago when I was working on a Sprint Sabbatical project with a coworker of mine Courtney Evans. Part of the process including doing image transformations and processing. These changes were fairly simple: perspective correction, normalizations, contrast, etc. I didn’t know much about how to do that – and still only know a little – so I turned to the opensource world to see what was available.

I landed on OpenCV (or Open Computer Vision). Its a pretty extensive project for doing image and video processing and sounded just right for what I needed. I also saw that they had a Java API to talk to their C++ libraries that contained all of the real work. Being trained and educated primarily in Java, I didn’t hesitate to try it and within a few minutes had things humming along with OpenCV and small Java app to do image processing.

Then we went to install it on our production environment.

We were using a CentOS box and had installed and configured other resources we needed (PHP, Node, MySQL, etc) without a hitch. But when we tried to build OpenCV (and yes, we had to build from source) things didn’t go so well. To keep things short and simple, we kept running into dependency and configuration issues of varying sorts and kinds when trying to build the library for Java.

Frustrated, I went back to their documentation to see what I could find. I didn’t get too far in the process when I discovered something: most developers that use OpenCV code in Python. I also realized there were better docs and tutorials for Python, which had frustrated me a little when using Java.

But here is the thing: I didn’t know Python.    

Not really at least. My only experience with it up to that point had been using it in physics Lab in college to illustrate vectors in 3D space (which was pretty cool), but I knew nothing about how it worked.

I was faced with that critical question: do I completely pivot and re-write my Java code in Python? I didn’t have a lot of time (Sprint Sabbatical projects are only 2 weeks long), so instead of just writing code and hoping things would work out, I really had to think through the pros and cons of each and if Python was the way to go. I eventually distilled my list into the following points:

Writing small processes is easier in Python than in Java

Java is – for lack of a better term – a little rigid and bureaucratic for small scripts and Python fit the mold perfectly. But hey, that might just be my opinion.

Python was already installed on our CentOS box (CentOS 7 with Python 2.7)

I know, I know. CentOS 7 is new and I could have installed 2.7 locally only on an older CentOS version, but we had a limited amount of time to get things working.

OpenCV didn’t require a new build for Python like Java did.

OpenCV has yum packages for CentOS that didn’t require us to build anything. It was as as simple as yum install opencv*

OpenCV in Python was much better documented than in Java.

The tutorials and references (including their own APIs) were just better and more reliable in Python.

After examining these points, I realized it was worth the time to learn what I needed to about Python and port my code. Eight hours later (complete with rants about Python white-spacing rules) I had successfully ported my Java code to Python!

This doesn’t mean every developer or team should come to the same decision as I did. In fact, I would be worried if you did. I was working on creating a rapid-prototype with only two weeks and had been encouraged to learn and explore tools, languages and frameworks in the process. This means that not only did Python fit into my technical needs, it fit into the project goals as well.

The bottom line of this is that as developers, we have to embrace the fact that the tools we use today might not be the tools we use tomorrow. Deciding on what tools that you might need to change to or from also needs to be well thought through. Embracing that idea and taking some time to really think through what I was trying to accomplish lead to building a prototype in two weeks with only one major glitch along the way. Hopefully I will learn (some) more Python in the near future.

p.s. Another developer here at Bandwidth wrote a similar article about how we think about the tools we use to deliver value to our customers here. I hope you check it out