Thursday, February 19, 2009

Python - The Never Ending Journey Of A Thousand Miles

Inch by Inch, Row by.... wait a minute, this is Python not Inchworm. Well, whatever.

Note, if you aren't a Monty Python fan it's hard to do the community suggested Python jokes, so you're stuck with my lame stuff instead. Joke writers cost money you know (and I'm free, err.. you know what I mean).

As I mentioned previously, I began learning Python by starting with 'A Byte of Python'. I'm enjoying it, and learning. Eventually I hit some example code showing how objects inherit class local variables, but objects don't share variables among themselves (downwards, not sideways).

The example made sense, and proved his point, but when I ran it on my machine it kicked out a Warning I didn't understand. So, I took my code and the warning message over to the Python IRC channel and they kicked it around a little bit - end result was they didn't like the example that much. They explained the problem to me, and I understood why the warning was there, but I didn't come up with a good way to refactor it so it didn't happen again.

During the conversation, someone suggested looking at Think Python. Turns out that one's available online under a free license as well. Off I went to take a gander.

It's quite good too. I like the way it talks about how to program, as well as how to program in Python. It assumes you have a decent knowledge of geometry and some trig which doesn't suit me all that well (I'd love to go back and enroll in those high school advanced math courses I never took). As I'm going along it has started using a 'turtle' program written in tk. It's kinda interesting to play with, but not my particular cup of tea. All in all it's enough of a contrast to the Byte of Python book I'm going to use both going forward.

I was also given a copy of the 1999 version of Learning Python from O'Reilly. Now I normally like and use O'Reilly books all the time, but this one seems a bit dangerous for a newbie to to use. It covers Python up to version v1.5, and while I don't know how much has changed since then, even a quick flip through shows me the style is different than I've been exposed to so far, and I don't want to start out learning depreciated ideas and syntax styles. Unless somebody tells me different, I'll just keep it around as reference material.

There was another interesting tidbit came out of that IRC channel discussion. At one point I indicated I was starting to get a feel for the syntax, but not the terminology Python users. A poster (sorry! didn't record who you were!) emphasised that getting the terminology right is important! His point was that you have to be able to think about your problems accurately and concisely, and to do that, you have to grok the terminology properly. Fuzzy logic leads to fuzzy programs. I wish I could quote him/her verbatim - it was much more compelling there than I can make it sound now.

Object orientated programming is starting to make more sense as a concept, but I still don't know how to design programs that use the concept properly. Breaking a problem down as a series of steps, then writing code that completes the steps is a logical way to program that that comes naturally to me (and most others I bet). OO doesn't seem to apply to that style properly, but I'm just not sure what to replace it with yet. Pointers welcome.

Completing the exercises (not slavishly, but doing them a little bit my way) has been helpful - picking up common syntax errors etc and getting my head back in programming space. Committing to bzr and pushing to launchpad working very well - just need to improve quality of my comments and get more consistent timing on my commits.

I have to say that the quantity and quality of information combined with the friendly to the newbie atmosphere I'm finding all over the 'Net is really encouraging me that Python truely is a great language to learn and use all the time! Let's keep it rollin'

1 comment:

  1. I taught myself Python using, yet another FLOSS book you might like to know about. How to design programs that use OO properly is a potentially huge subject. I wouldn't worry about it too much to begin with. But when you start to write bigger programs, start thinking about them in terms of the bits of data you are using, what will happen to them, and how they are related to each other. This is very different to thinking about the program in terms of steps, and may help you to structure your programs in better ways, including OO.