No Open Blockers

I’ve been getting into Django recently. I’ll go into it more in another entry, but I ran into a small issue where my database seemed to get out of sync with my model. Running syncdb didn’t throw any errors, but when I tried to access the model from the server I’d get an error about “no such column”, even though I could see it created in the generated DDL.

It took me a bit of digging (in other words, it wasn’t in the tutorial), but there’s a manage command to reset the database for a particular app. Running that and re-syncing my database got me moving again.

python manage.py reset [appname]
python manage.py syncdb

I’m not completely sure why, but I’m a bit embarrassed to admit to Planet Fedora how little my Python experience is; the majority of my experience is in Java. I was able to read and bug fix the Python code in Spacewalk, but I hadn’t really dug deep into my own project. Now that I’m not teaching any longer and have some free time (one of my main reasons for quitting), I can finally sit down and dork around with the language. After spending some time working on some basic games and a simple IRC bot, I figured I’d step back and think about what the transition from Java to Python has felt like.

Don’t Fear The Whitespace

I constantly hear people mention the indentation in Python as the first thing when talking about moving to the language. Not only is it not as jarring of an experience as people make it out to be, it’s downright awesome. I’ve always been compulsive about my code format anyway, so the biggest difference is the lack of curly braces.

Collections Are Awesome

It’s much lighter-weight to throw things into a list or map (dictionary in Python) than it is in Java. Get out of the mentality that you have to jump through import hoops and rigid notation to create, access, or return collections. In Python, they even let you do cool things like assign multiple variables as a return from a call:

exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()

Looping Feels Weird At First

I got a little thrown off by this initially. Most loops read really well:

for square in openSquares:

However, when looping through a set of numbers, you need to use the range method:

for i in range(0, 10):

Looking at both of those examples brings me to my next point…

Don’t Forget The Colon

This keeps throwing me off, but after declaring a function*, loop, or if statement, don’t forget to end the line with a colon. I’m happy to be rid of curly braces, but I get over-ambitious and forget the colon too.

Don’t Over-engineer Configuration

Depending on what you’re doing, you can likely just stuff configuration values into a script and import it (not needing to compile really is liberating in this respect). That’ll also give you the use of lists and maps by default. If you’re not reading between the lines I’ll spell it out: no need for XML-based configuration, which is one of the more evil trends in Java.


There are definitely more things I could mention; don’t take this to be the only lessons I’ve learned (any other hints/tips are appreciated). But I do want to avoid a mammoth blog post that causes readers to go into a zombie-like trance, so I’ll stop it here for now. I do want to thank Devan (dgoodwin) and Jesus (zeus) for dealing with the Java-veteran-turned-Python-noob and not finding a way to crash my chat client to avoid more questions.

* I haven’t seen a solid explanation of “Call them ‘functions’ because you’ll sound like a Java guy calling them ‘methods’”, but this feels like something where using the wrong term will make me stand out as a Java developer in a Python world. So I’ve been advised to take a militant approach of “Yes, I’m a Java guy learning Python, deal with the occasional terminology missteps.”

PageControl pc =
  PageControl.getUnlimitedInstance(); // gulp - I assume we can fit all package versions in mem

It’s been a while since I’ve come across code that talks to me. Even longer since I’ve seen code emote to me. The good news is that, so far at least, we haven’t had an issue with package versions in memory.

any joy on reproducing?

I sit in a number of non-Spacewalk/Satellite chat rooms at work. This was just seen in a conversation in one of those rooms discussing… well, to be honest, I don’t actually care what bug they were talking about. Taken out of context is way funnier.

...
// Now we filter out an 
List retval = new LinkedList();
...

Shit. Ok, so it’s not too much code after that to see what the filtering is doing, but the comment still left me hanging.

1
2
3
4
5
6
7
8
9

try {
    String line = input.readLine();
    while (line != null) {
        line = input.readLine();
    }
}
catch (IOException ioe) {
    logger.debug("IOException...really need better handling here");
}

Everyone, at one point or another, is guilty for just swallowing an exception. Java tends to be a bit trigger happy with its checked exceptions (especially in the IO packages), so it’s inevitable to be in a position of having to deal with an exception that admittedly will probably not happen while trying to get something else accomplished.

The nice part is that I’m cleaning this up and actually providing the better handling. The cool part is that I’m using code I wrote for CodeTurtle to do it.

I’ve been reading Dreaming in Code for the past week. I forget where I first heard of it, but after a recommendation from a coworker on the Spacewalk team (thanks Partha) I finally followed through with checking it out.

The subtitle does a good job of explaining the book’s purpose: “Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”. I hesitate to call it a case study in software projects because I don’t think it does justice to the book’s relaxed, conversational style. Rather than reading like a formal study, it’s the story of the development of Chandler an open source personal information manager with high goals. Rosenberg also provides a ton of related information to help frame the choices the Chandler team had to make, which increases the book’s audience significantly to include non-professionals.

I wish I was in a position to assign required reading for CSC majors. I’m not sure what class this would fall under (the most likely candidate is Software Engineering). Even then, the bigger challenge is convincing students of the value.

In short, anyone considering a career in programming needs to read this book. It provides an incredibly good insight into what it’s like to work on an actual project, an insight that students normally only get with experience after they’d graduated. Like I said, it’s presented more as a story of what happened rather than a technical manual, so it’s not painful to read.

But I cannot stress enough how much I would have appreciated such a detailed look into a real software project before I started on my career. Software Engineering text books describe what to do “by the book”. This book shows you a more realistic view of how those theories and practices can (and often do) go wrong.