Tests stats

We have 52 unit-tests now which cover as much as 89% of the code (not counting the tests themselves). The test-to-production code ratio is 1.121 KLOC / 1.533 KLOC = 73% or a share of 42%.

I made the script for counting LOCs available here: link, enjoy!

boost.python

Today I have tried boost.python and was impressed with its power and simplicity. Using it, I was able to marry an utility-level C++ library with Python 2.6 in just three hours, wasting at least half of the time purily because of my Saturday's stupidity.

The only thing that worries me if I think about providing Python scripting for large-scale application is compilation time of the bindings provided by boost.python -- these templates could eat my PC alive.

Weird in

Just discoverd that "" in "abc" evaluates as True, which is on my opinion counter-intuitive. It's quite strange that I can't find it listed as a common Python newbies' error. Does everybody read manual then? :)

Development mode: relaxed

Sorry folks, due to technical complications, release 0.1 isn't gonna happen in October. More realistically, it would be November or December, definitely this year.

Deep copy of a list in 4 bytes

In Python, when you do assign one list variable to another, it actually assigns an extra reference to the same list object, thus making any modification to one of variables be effectively reflected by another. This is what called "a shallow copy".

Sometimes, it's not the intent and you really want to obtain two independent copies of the list object, that's what called "a deep copy". Omitting trivial iterative by-element copy, there is at least three proper ways to create a deep copy of the list object.

1. Invoking a builtin function named copy.deepcopy() which is designed to do deep copies of anything and - duh - applicable to lists;
2. Calling list constructor on the source object: a = list(b), which is nice, because it's clear and costs only six bytes of code;
3. And finally, making full slice of the source object: a = b[::], which might be not as fast as approach №2, but it's only four bytes of code!

Multi-line strings

I've just realized that multi-line spanning string literals which give me so much pain could be collapsed to single-line literals for the sake of obfusation! Yes, replacing carriage returns with \n's will result in adding one extra  byte per line but, honestly, who cares about this novadays?

"""I hate you 

multi-line string literal guys.

Prepare to die."""

Mercurial branching guide

I have found a pretty good Mercurial branching guide, with comparison to git on Steve Losh's blog: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/.