When’s a string not a string

When it’s intertwined — ok, bad joke.

I’m currently “fighting” (playing) around with the python storm ORM system and had the following problem (not the real code, but demonstration).

What I wanted to say is:

1find(..., employee_title == 'CEO')

However this didn’t work, I had to say:

1find(..., employee_title == u'CEO')

After a bit of discussion down a mailing list, I got the “classic” answer back.

Maybe you think it’s annoying, but it’s correct, and doing it with automatic conversion is error-prone.

While I can see the point, it’s one of my pet peeves with Python specifically… Which is that there are quite a few programmers who are overly type aware, but yet are working in a language that is “late typing”.   You would think that in a world where one of the contributions to design is duck typing, would be the idea that last mile type enforcement is a bad thing.

What’s really funny is that when you put this in context of this post I read this morning about 100% code coverage the following can be observed.

To simply state a goal of 100% code coverage for a test suite in the presence of late typing is a red herring. 

 1def foo(flg) :
 2   if flg :
 3       x = u'TEST'
 4   else :
 5       x = 'TEST'
 6
 7def bar(i) :
 8   x = ""
 9   x += foo(False)
10   return x
11   
12def unitTest() : 
13  j = foo(True)
14  for i in range(1,3) :
15     k = bar(i)

I’ve got 100% code coverage in (flawed) unit test, but the problem is that since the typing is late there is the potential for lots of latent bugs. Eiffel! Since python isn’t going to give into true typing, it might as well adopt PEP 316: Programming by Contract to enable a test suite to enforce pre/post conditions to insure a function can only return specific types.

Parting thought after I did a bit of investigation: Python Contracts – plus it improves the documentation of functions (another personal pain point)