Wednesday, November 21, 2012

Things I Like About Python

Back in May I wrote a popular post about which was a better beginners language: Processing or Python.  Although I concluded that Processing was better for the audiences I tend to have in mind (that is, nontechnical members of the general public), that doesn't mean I think Python is a bad language.

I finally had the opportunity to use Python for my own project.  I have been making a simple iOS QR code scavenger hunt / story game as a (very) side project for a while now, and am trying to give it the final push to completion.  The game is defined in a plist file. I wanted to generate the QR codes automatically from the data in that plist.  I also wanted to arrange the generated images into contact sheets with the text associated with each code written underneath.  I figured this was the perfect opportunity to use Python for a real purpose instead of just as a teaching language.

The very best thing about Python is the fact that no matter what singular unit of work you need to do, you can almost always find freely available code online that does it.  QR generator? Check.  Contact sheet creation? Check.  Help with the imaging library, including drawing text? Check.  Put the pieces together and do some customization to suit my purposes, and I was off to the races.

I also like the 'scriptiness' of the language.  I felt that I didn't need to work hard to make robust and reusable code. So long as it worked for my purpose here, that was good enough.  This is a rare feeling for me.  I usually feel compelled to make the code as general and 'nice' as possible.  I loved being able to do what I wanted quickly and not worrying about what the result looked like.

But that's sort of a downside, too.  When I stepped back to look at the code from a beginner's perspective, I noted how messy and likely difficult to understand it had become.  I remember reading that Python inherently helped developers write good code (thanks to, for example, indentation to signify blocks of code).  But this experience made me believe the opposite - it's so easy to write fast code that it can quickly end up being kind of ugly.

I also had a heck of a time getting everything set up on my Macbook.  Python comes installed on OSX, but it's usually kind of old.  So I downloaded and installed Python 3.  After wrestling with the OS to get it to actually use that version for most Python-related things, I quickly found that the libraries I was trying to use didn't really work with this version.  After several hours I ended up reverting back to the newest release of version 2.  If I was a beginner trying to accomplish some relatively simple task, I would have been turned off the whole thing pretty quickly, if I even understood how to set up the environment in the first place (and I doubt much of the general public would, given how much time you are likely to spend at the command line).

So, all in all, I really like Python for my own purposes as an experienced programmer.  But I'm still favouring Processing (or, even better, something like Scratch or some not-yet-existing language theorized by Bret Victor) as a beginner language.  I could see Python being really handy once the basics are taught and some confidence is built, but I am still fairly sure I wouldn't want to begin with it if I had a choice.

6 comments:

gasstationwithoutpumps said...

My highschool junior son and I are converts to Python (me after 30+ years of using C++). He is currently TAing a course that is being taught to elementary through high school kids who know no programming. They spent the first day of class setting up Python on a variety of different machines, mostly provided by the students. Only a couple of the Windows machines gave trouble, and that was resolved in the first class by the TAs. So I don't think that installation of Python is a significant barrier to use by beginners in a classroom setting (it may be in a MOOC, where no one can help the clueless or frustrated).

Python is good for rapid prototyping, but rapid prototyping can lead to sloppy programming. I require students to program in Python in my graduate bioinformatics class, because they need to get fairly substantial programs done in a week. I do require them to use good docstrings and comment all their major variables—something that almost all of them struggle with. Only one student this year seems to have entered the class with the concept of proper internal documentation fully realized, which makes me want to send my son to the college where this student was trained.

I think that Python is an excellent early language for students (after something like Scratch), and an excellent scripting and rapid prototyping language, but the lack of enforceable interface specs makes it somewhat unsuitable for projects by large teams or for maintenance over a long time.

Gail Carmichael said...

Thanks for sharing your experiences! Very interesting, and everything makes sense.

I agree that having some time face-to-face to set things up would make a big difference. If I was doing a shorter workshop I don't think I'd want to spend that time, but during a full course it would be totally feasible.

Christian Muise said...

You're missing a huge aspect of the python ecosystem though. For example, if you want to start messing around with python and all of the cool math packages it comes with, try Sage:
- http://www.sagenb.org/

If you want to provide a tutorial or teach people python, then IPython is an excellent way to do so:
- http://ipython.org/

These projects let you write things in a very tutorial-like manner, and give you (and the students) the opportunity to actually change the code on the fly and re-run it to see what happens.

As for sloppy code, any language will allow for that. And any language that lets you crank out a useful script / bit of text in minimal time will inevitably lead some people to producing ugly stuff (bash scripts, perl scripts, etc). That shouldn't ever be a negative on the language though, especially if the faculties exist to easily make your code look beautiful (and I think the doc strings go a long way towards that).

Gail Carmichael said...

That's all fair, Christian.

I still think it would be better to start with something more Scratch-like at first, but I think after that Python would be great. And I will definitely check out some of those links, because I was missing out on them! ;)

As for the messy code, it's totally true that all languages could have the same issue. I did find it interesting that Python seemed to make me want to write less pretty code for some reason. I also worry about how readable examples and such would be that people would download (which isn't necessarily an issue for many teaching contexts).

Doug Blank said...

I absolutely agree with your overall feelings about Python and Processing. But we need not be happy with picking one or the other: how can we combine the best from both to create an even better environment? We have been working on a system which allows a mixing of contexts (art, robots, graphics, etc) with different languages (Python, Scratch-like, Scheme, etc).

For example, we have a Processing library which can be used in Python, and the same library can be used in our Scratch-inspired language, Jigsaw (and others). We have to make certain sacrifices (not all Python programs can be used with ours, we have our own graphics system, etc) but we gain a lot of other properties (control over entire "stack", language interaction, stepper/debugger for all languages, etc).

FYI, we are always looking for contributors for helping shape better environments for a more broad, diverse group of computationalists. For more info, see http://calicoproject.org/

Gail Carmichael said...

That sounds really interesting, Doug! I will definitely check out the project's website.

Post a Comment

Comments are moderated - please be patient while I approve yours.