After some more hours pouring over the sources, ITK could have observers that are usable from Python. Behold!
The previous patch was accepted, let’s hope this one gets in too.
After far too many hours staring at Cable and Swig code, I can now catch ITK C++ exceptions as Python exceptions. Yes, of course the resultant patch is pitifully small. See my posting.
Once again I have come to the conclusion that a good source-analysing code editor such as Visual Slickedit is invaluable when trying to understand other people’s complex projects.
Yesterday, a group of us went to a gaming and gaming history exhibition in Tilburg. It was marvellous to see (and play) all the games I wasted my time (and 20 ZA-cent coins) on as an arcade-frequenting dude. They even had an old Sinclair Spectrum 48K on exhibit… this is the computer I grew up on.
In anycase, amongst one of the 120 games that you could also play, Paul introduced me to Bust-A-Move 4 on the Sega Dreamcast.
When editing Python text, I usually use emacs on Linux and XEmacs on Windows. However, I would love a cross-platform Python development environment in the style of Visual Slickedit or similar. It should have code-completion (for the umpteenth time, dabbrev in emacs is NOT code-completion!), it should show calltips (incorporating the relevant docstrings) when I’m instantiating objects or calling functions and it should have some kind of graphical object browser. It’s syntax highlighting and auto-indentation should be at least as good as that of emacs. Emacs has caught numerous programming errors before they even happened due to its auto-indentation.
MijKopThee, a popular Dutch blog, has a link to this cool clip of very, err, enthusiastic Mac user. Be warned, it needs a Windows Media 9 codec. Doh.
For your reference, I like Macs. *pet pet*1
1 I’m petting my virtual Mac.
Update September 13, 2010: Charlette reported in the comments below that the clip linked to above has disappeared. Some searching seems to indicate that the below Youtube clip is the same:
Finally I too went to see Reloaded. We went to a particularly cozy little cinema in Delft called The Apollo. This is a “Service Bioscoop”, meaning that you have a little table in front of you and can press a button to have a waiter pop by and serve your favourite drinks and snacks. Smoking is also allowed. As we haven’t been taking part in this in- and exhalation-driven activity for a while now, this point isn’t so high up on the list of advantages, but it definitely does contribute to the cozy atmosphere. We will most definitely be going back there… In case you were wondering: No, the big screens and digital sound systems of the surrounding cities are unable to drag us away from our beloved Delft, thank you. There’s nothing like taking a relaxed walk back home from the cinema along a Delftse gracht.
This is from the first recipe in my brand-new Python cookbook. It’s quite obvious, but it hasn’t really struck me before. Well doh.
In most languages, swapping the values in two variables means using an intermediate temporary variable, e.g.:
int a = 1;
int b = 2;
int temp;
temp = a;
a = b;
b = temp;
With the tuple packing and unpacking in Python however, we don’t need no steenking temporary variables!
a = 1
b = 2
b, a = a, b
Obviously this principle scales to any number of variables, e.g.:
Have a look at this brief snippet:
In [2]: a = range(10)
In [3]: 3 in a
Out[3]: 1
In [4]: 3 not in a
Out[4]: 0
In [5]: not (3 in a)
Out[5]: 0
Input/output 4 should strike you as a tad strange if you don’t know Python
that well but are familiar with similar constructs in other languages. At
first glance, it almost seems like the sense of an operator can be negated
with the not
operator.
This should be very useful:
In [5]: class oldObject:
...: ....def __init__(self):
...: ........self.someVar = 1
...:
In [6]: o1 = oldObject()
In [7]: o1.someVar = 2
In [8]: o1.someOtherVar = 3
This is of course expected behaviour. Have a look at this though:
In [9]: class newObject(object):
...: ....__slots__ = ['someVar']
...: ....def __init__(self):
...: ........self.someVar = 1
...:
In [10]: o2 = newObject()
In [11]: o2.someVar = 2
In [12]: o2.someOtherVar = 3
AttributeError: 'newObject' object has no attribute 'someOtherVar'
Neat huh? In short, deriving from the new Python class object
means you have
a “new-style” object. Amongs other things, this means that you can define a
__slots__
list which will prevent the use of attributes not in that
list. These objects are available from Python 2.2 onwards.