Thanks to datainadequate's comment on an earlier post, I've got another book to take a look at - Dive Into Python. I did see mention of it before, but the tag line saying it was 'for experienced programmers' scared me off without looking at it further. What the heck, I'm game this time around.

Also of note, I'm hoping to have current versions of both O'Reilly books Learning Python and Programming Python in my posses ion soon, so once my eyes quit glazing over from the information overload I'll try and post some further reviews of how I think they all stack up.

Maybe I should have been a librarian :-) I wonder if librarians that like too read too much end up like cooks that like to eat too much....

Stop Vim From Creating Backup Files of bzr_log entries during commit

Here's a handy tip from Paul Brannan. I pulled this from a Launchpad bug report.

I use Vim as my default $EDITOR. When I commit a change using bzr, it opens Vim up and lets me type my comments in.

Unfortunately after I save and edit, it leaves behind a bzr_log backup file with a ~ in that directory too. I want Vim to make those backup files normally, but not when doing bzr commits.

Paul to the rescue:

I solved this with:

~/.vimrc:
filetype on
filetype plugin on

~/.vim/ftplugin/bzr.vim:
set nobackup

(See - it pays to read bug reports! Now go check out all the other ones and let me know the good parts ok?)

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'

A Space In The Right Place Saves Nine

Experienced programmers please set down any hot liquids before proceeding. The following comments are from a beginning programmer, and as such, will likely promote laughter among those who know better. That's why I'm writing this - you guys just can't regress all the way back to this level of ignorance easily :-)

The one thing everybody knows about Python is that whitespace is significant, and it's really a pain. OK, so now that I can do 'Hello World' in three - count 'em three! - different scripting languages, what do I think about Python syntax?

I just don't see why everybody thinks it's hard. To me, it's a breath of fresh air! So far, the only time I've seen that white space matters is leading whitespace to set off a block of statements.
There's no 'end' to that block except the ending of the indentation. OK, so it's something to keep in mind. On the other hand, bash's use the $ when you assign the value and not when you use it is a lot more confusing. And don't get me started on Perl. When to use a ( vs a { vs a [ is a lot harder to figure out, and $ or % or @ for variables ain't exactly simple either. Yes, Perl logically hangs together, and I get the fact that you should know which symbol to use when based on what you are trying to do, and what kind of data you are storing. I even appreciate the fact that it's a form of error checking - because if you use the wrong symbol because of a logical error it'll catch it for you.

On the other hand, in Python a variable is a variable regardless of the contents. The programmer has to keep it straight in his head rather than the syntax enforcing it. It might make things more error prone, but it sure makes it easier to read. The lack of end of line characters in particular is refreshing, unlike bash's 'you might want to use a semi-colon here - or not...

So, if you were thinking that counting spaces was a necessary evil in Python, forget it, and just try it out and see what you think!

How's It Going?

When we last saw our brave hero, he'd just emerged victorious from his struggle over the dog pack of FLOSS project hosting choices, but the looming battle against the three headed dog of Python, Bazaar and Object Orientated Programming was yet to begin.... Will he survive to see another day?

Sorry - Rocket Robin Hood flashback. Thanks Teletoon Retro....

Just a quick update on where I'm at. I've set up a project on Launchpad. That was a straightforward click n' drool kinda thing. Just fill in the blanks where required. I spent some very constructive time reading the documentation. It's got lots of information on all the various Launchpad features (and there are quite a few) but I was most struck by the amount of 'why' as well as 'how' in the information. Since I've not been exposed to project management per se before, it was good for me to see how the website was designed around a project flow, rather than the other way around, and expose me to the common steps most projects go through.

I had already registered my GPG key when I signed the code of conduct earlier, so I just had to create and upload an ssh key for use with bazaar. It took me a bit of twiddling to get that working, mainly because I wanted a separate launchpad key from my regular ssh key. My regular key is already used in too darned many places. The twiddling was purely self inflicted - launchpad was working perfectly all along :-)

Next up, I went looking for some docs to get me started on learning Python. A quick inquiry in the (newly created) Python group on identi.ca pointed me at 'A Byte of Python'. Turns out it's licensed CC and available for download.

As I work my way through the examples, I've been creating the them in GVim. Another bit of Googling followed with an identi.ca query found me some pointers for using Python in Vim. As I've created each example and tested them, I've committed them to a +junk repository and pushed it up to Launchpad. This post by Paul Hummer made getting that all set up painless and simple.

Are you seeing a trend here? I'm using Linux, SSH, GPG, GVim, Identi.ca, Python, A Bite of Python, and a blog posting by a Launchpad dev. All of it FLOSS. All of it no charge. All of it quality information and tools - downloaded off the internet by nothing more than the sweat of my little pinkies. It's just amazing when you sit back and think about it. It's downright flippin' awesome in fact.

Thank you one and all that made this happen, and continue to make it happen. Hopefully I can do my little part too, and keep the steamroller rolling.