Until recently I’ve been using Python 2.3.x almost exclusively and I thought it was about time I get more familiar with what 2.4 series has to offer. I’ve skimmed the list of new features when point zero version came out and found some things that I like (e.g sets) and some that I disliked (e.g. decorators).

So, this time I invested a bit more time to actually read and understand what was on offer and how these features came about. I still haven’t found a need or a sympathy for decorators, although I can see why some people want them. Personally, I believe they’ll more likely be a cause for less readable and harder to understand Python code than they prove to be useful.

I still think Python is a wonderful language, but gone are the days when I was looking forward to each release and goodness it brought. These days I’m afraid to look and discover another feature that helps more with keeping habits from other languages than adding something new and genuinely useful.

I like minimalism in all things and therefore see every new feature as a burden that should be more than offset by its usefulness. I’m not a language designer and hence can’t really say or tell if Python is going down the wrong track, but there is something that I find most annoying.

I’ve been thinking about languages quite a lot recently; how we use and abuse them and what impact our language proficiency has on our communications. There’s one thing I find very different with programming languages than those used for normal human interaction.

There’s very little optional about them.

It really gets my goat when a language feature is defended as being optional. You may have a choice in using a feature, but you certainly don’t get a choice in learning and understanding its use. Even if you don’t use it yourself, you’ll quite likely have to interact with somebody else’s code, which does and unlike with English, it’s not enough to just get a sense of meaning from its context. You actually have to really understand what it does and hence need to be familiar with feature itself.

It might still be worthwhile to add it, but let’s not pretend when we do that it’s completely optional.

P.S: Isn’t it amazing that after all these years, we still have a global interpreter lock? Wouldn’t it be better if we worked on removing that disgrace?

I thought Harold Evans’ last column was quite good.

It’s no shocking revelation that I’m not a native English speaker. In fact, my mother tongue is Slovenian; a fairly difficult language to master even for willing. Although my (mis)use of it leaves much to be desired, I’d like to think I have a better grasp of it than of English.

Still, every now and then I happen to get into trouble because of a misunderstanding that is sometimes caused by as little as a subtly different perception of a word. Usually such problems can be easily spotted and rectified since nuances are much clearer to me in a language I’ve used for more than three decades.

However, I was less lucky when dealing with different cultures using English. One such occasion was using word hate improperly, as you might use it in Slovenian by implying a stronger disliking of something, but not an actual hate. I try not to transplant use of a word or a phrase between languages, but I’m sure I still make mistakes like this.

I also lost international friendships through years. Most of them probably because of my cultural ignorance and sometimes it seems the language we used came between us. I came to believe there’s a risk in knowing language well enough for people to assume you know what you’re talking about and not well enough to actually do.

So, does anybody have any personal language related horror stories to share?

Play with fire and you’ll get burned.

I’ve just spent two days hunting a bug that just didn’t make sense. No matter what I did, there was at least one browser, which didn’t want to behave properly and it was driving me nuts.

Finally I gave up and decided there’s nothing wrong with my code and the fault must be with the browser. And so it was, up to a point. Or not, depending on your point of view.

The problem was a timing conflict resulting from a use of framestack technique and the way modern browsers work. Browsers don’t wait for the whole page with its data to load, before they display it to users. They display as reasonable presentation of received data as possible while they are trying to load the rest. For example, onload handler set to body tag is triggered when body of HTML document has loaded, but possibly before images and other external resources have. When they do, page layout might change somewhat and if your script is reading and using layout data in the meantime, it’s quite likely it’ll end up using wrong values.

The easiest (and right) way to fix this is to start javascript with window.onload , which is triggered when everything has loaded. This might be a problem, if you’re using something like framestack to avoid reloading page on subsequent visits, but at least in my case I’ve decided that the cleanest and easiest solution was to use window.onload and just force reload of problematic page on each visit.

It’s also possible to get in similar timing conflicts by using innerHTML method. If you try to stuck a large piece of HTML inside a page using innerHTML call, you may encounter an unwelcome surprise. Reason for this is that at least some browsers don’t wait to parse and insert data in DOM before they proceed to the next statement. Injection delay is usually barely noticeable, but big enough for statements that manipulate inserted data to fail, if they are in close proximity to innerHTML call.

You can’t necessarily avoid innerHTML problems with window.onload, but you can by using (more cumbersome) DOM methods.

It still annoys me though that I knew all of this and wasted two days just because I didn’t think of it.