It has been way too long with­out post­ing a longer item, so... I re­ci­cled a script I wrote for a cus­tomer, and here it is:

A python script that lists (al­most) all email ad­dress­es in a qmail sys­tem.

Al­so, a slight­ly tweaked CSS, thanks to Georg!

I am try­ing to do some­thing which is, I think, pret­ty cool, in python.

How­ev­er, I like show­ing things work­ing, and I am hav­ing trou­bles with the last fi­nal step on what I am try­ing to achieve.

Since I know a few bet­ter python pro­gram­mers read this...

Sup­pose I have this:

def fun(self,x):
        pass

class C:
        pass

C.a=fun
C.b=fun

What code should be in fun() so that it fig­ures out if it has been called as C.a or as C.b?

I am think­ing some­thing like read­ing the high­er step in a back­trace, but I don't know enough python to fig­ure out how to do that.

A short tu­to­ri­al ex­plain­ing how to cre­ate re­us­able wid­gets us­ing PyQt.

In a whim, I checked out kde­bind­ings/d­cop­python from KDE's CVS.

I see the READ­ME: dcopy­thon is bro­ken

Then I said to my­self: maybe I can fix it. And you know what? It seems to be not bro­ken! :-)

At least for sim­ple da­ta type­s, that is.

dcop­python lets your python pro­gram be­come a DCOP serv­er or clien­t.

A DCOP serv­er is ca­pa­ble of be­ing con­trolled by KDE's kd­cop, and is a very sim­ple way to make your ap­pli­ca­tion ex­ter­nal­ly script­able.

A DCOP client is some­thing that con­tacts a DCOP server, so that means you can con­trol and script KDE ap­pli­ca­tions (or oth­er DCOP server­s) from python script­s.

The neat­est thing here is that this stuff does­n't re­quire Qt!

I in­tend to use it to make some of my apps ex­ter­nal­ly script­able with­out PyKDE.

There's a prob­lem of­ten used to show the un­in­tu­itive na­ture of prob­a­bil­i­ty, which has be­come very well known.

In that prob­lem a con­tes­tant in a gameshow has to choose be­tween three doors (A,B,C), on one there is a car, on the oth­er two are goat­s.

Af­ter the con­tes­tant choos­es, the host opens an­oth­er door and shows a goat.

Then, the host of­fers the con­tes­tant the chance to switch his closed door for the oth­er closed door.

Should he switch?

The in­tu­itive an­swer is "it does­n't mat­ter", be­cause there's two doors and one car, so it's a 50-50 chance.

But the re­al an­swer is that it does mat­ter, be­cause it's a 33-67 chance!

While it's sim­ple to show this to be the case to a sta­tis­ti­cal­ly-e­d­u­cat­ed dude, it's some­what hard­er for a lay­man.

In fac­t, I think most ex­pla­na­tions suck.

Here's my shot at it:

If you were of­fered the chance to switch be­tween your closed door and the oth­er two closed doors, would you take it?

The in­tu­itive an­swer to that is of course, yes, be­cause it's 67-33 for the car to be on the oth­er two doors.

Now, re­gard­less of where the car is, can the host open one of those two doors and show a goat? Of course, yes.

So, would you feel your odds went down be­cause the host showed one of your two closed doors had a goat be­hind it? No, be­cause he could al­ways do that, and you know there was (at least) one goat there!

So, what dif­fer­ence does it make if one door is open or not?

I don't ex­pect this to con­vince any­one, re­al­ly, but just in case, I have a python im­ple­men­ta­tion of this prob­lem (goat­car.py :-) if any­one wants it, if em­piri­cism can con­vince you ;-)