Everyone knows that in Python variables are just references and passing such reference to function effectively copies value of the reference to functions local scope, hence any assignment within function has no effect on original variable. Knowing that, this took me by surprise:

>>> def add_eggs(foo):
...     foo += ['eggs']
...
>>> spam = ['spam']
>>> add_eggs(spam)
>>> print spam
['spam', 'eggs']

This seemed to me as an error in Python interpreter, but after checking language reference I discovered it’s not; it’s intended behaviour (emphasis is mine):

An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once. Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead.

Quoted after: python docs

I’ve just got hit by one of really typical errors while writing simple value type in Python. Consider following code:

class Simple(object):
    def __init__(self, val):
        self.val = val
    def __eq__(self, other):
        return self.val == other.val

The class Simple overrides equality operator delegating it to it’s value. Seems dead simple and easy for the first time. But not quite so. What will following snippet print?

a, b = Simple(3), Simple(3)
set_a, set_b = set([a]), set([b])
print 'a == b: ', a == b
print 'set_a == set_b', set_a == set_b

You’ve guessed it: True, False. This is because two sets may be equal only if all elements hashes are equal. So I thought I will fix it with this:

class Hashimple(object):
    def __init__(self, val):
        self.val = val
    def __eq__(self, other):
        return self.val == other.val
    def __hash__(self):
        return (self.val * 5) + 7

Seems better, but look at this snippet and guess once more:

a, b = Hashimple(3), Hashimple(3)
set_a, set_b = set([a]), set([b])
print 'Hashimple'
print 'a == b: ', a == b
print 'set_a == set_b', set_a == set_b
print 'a != b', a != b

True, True, True?!? Well, Python will not imply that a != b , not even when a == b.

This bug has been made thousands times by thousands of coders, it occurs not only in Python, but also in various other languages (Java, Ruby), it’s been described in lots of books, but I just keep forgetting about it. Maybe writing a blog post will help me remember?

Docs: __eq__, __hash__

Since the Steve Sounder’s High Performance Web Sites everyone knows to set far future Expires header on their static assets. What he didn’t say was how to deal with the file changes. You can’t instruct browser to download the file so you actually have to change the file’s URL.

Ruby on Rails handles this by automatically adding file’s timestamp as a query-string when using build-in helper methods — simple and not requiring server-side URLs rewriting. This is good enough, but only for files accessed from HTML directly and doesn’t work for files accessed from CSS: background images (unless you have dynamically generated styles).

I was thinking for some time about those background images, because they can be heavy and if you’re not using CSS sprites they make lots of requests. As I don’t like dynamically generated style sheets, I didn’t want any additional processing. And so it came to me: why not incorporate some changing value into the domain name? You could put a revision number or a timestamp in domain name of your statics server, just like this: static-1566.example.com. Both Rails and Django provide easy ways to change static assets domain.

This requires you to set-up wildcard subdomain, but is’s easier than processing CSS files. It works because url function in a style sheet is resolved using the style sheet’s own address.

PS: This is only a brain-dump — I didn’t test it.

Clean Code is the best book I have read in last six months. In this book Robert C. Martin shares his great experience from the programming battlefield.

The book has a very good style. It guides you through refactoring of reams of Java code as if it was solving riddles. It’s not about high design, though, it’s about handling the code at a lower level: at the level of organizing classes, functions and blocks. It’s about writing a beautiful and readable code.

It’s also a book on craftsmanship. The author has emphasized this many times on his blog: being a craftsman-programmer means taking responsibility of producing good code only, just like being craftsman shoemaker, is all about making good shoes. And exactly the same way there are principles and best practices in both professions.

The uncompromising style helps the reader not to lose himself within arguments, but if you don’t like what Robert Martin says about certain principle, that’s very good (unless you can’t provide any arguments to back it up).

All in all it’s a very good book for anyone who wants to write better code. Get your own copy now and no worries! You’ll like it.

Quick and obvious info: I moved to wordpress. That’s kind of treason: wordpress is not in Python, but after evaluating it for a few hours it seems nice and very usable. I don’t know internal code, but from outside it’s quite good piece of software. Theme used: Elite.