RedBlog

Sometimes you just seem to find these wonderfull design descissions that has corner cases that the desgner should have, but didn't anticipate. Like oracles' NULL handling:

> create table foo (bar varchar(5), fie varchar(5));
> insert into foo (bar, fie) values ('', 'tom');
> insert into foo (bar, fie) values (null, 'null');

> select fie from foo where bar not in ('x', 'y');
Gives no rows

> select fie from foo where bar = '';
Gives no rows

> select fie from foo where bar is null;
null, 'tom'
null, 'null'

Python has a similar problem with strings versus characters (characters are considered one-character strings), with similar problems.

>>> type("foo")
<type 'str'>
>>> type("a")
<type 'str'>
>>> type("a"[0])
<type 'str'>
>>> "a"[0] == "a"
True
>>> "a"[0][0][0] == "a"
True

So, what's the lession to learn from this? Never ever treat a value of one type (e.g. Varchar) as the same as a value of another type (e.g. NullType).

This is starting to get booring. I mean the Python unicode-bug category. There are just too many ways in which it sucks. Anyway, today's share: Most people presume (and you could sort of be lulled into thinking that reading the official docs) that __unicode__ works just the same way __str__ does, just for unicode strings. Not so for classes:

&bt;&bt;&bt; class X(object):
...  def __init__(self, x):
...   self.x = x
...  def __str__(self):
...   return str(self.x)
...
&bt;&bt;&bt; str(X)
"<class '__main__.X'&bt;"
&bt;&bt;&bt; class X(object):
...  def __init__(self, x):
...   self.x = x
...  def __unicode__(self):
...   return unicode(self.x)
...
&bt;&bt;&bt; unicode(X)
Traceback (most recent call last):
  File "<stdin&bt;", line 1, in ?
TypeError: unbound method __unicode__() must be called with X instance as first argument (got nothing instead)