Unintended consequences

Yesterday I was raving about wxPython and how it was letting me do “cool” things. Today I discovered it was letting me do a lot of things, some of which aren’t so cool… It turns out that my call to wx.Window() wasn’t 100% correct. As in I was passing bad/incorrect data to the constructor. Yet, the hardy little wx.Window() class kept on a rollin’. I don’t like that. Python is pretty loose when it comes to variables and data types, that’s one of it strengths. In this case it is a problem. In my call to the class I was passing in a wx.Frame object, a int, and a string. And it took this, and everything seemed to run. Calls to getClientSize() kept returning (20,20) which is kinda odd, I was specifying 1024x768. But after running a method the called a bunch of dc related methods, the getClientSize() method began returning (1024,768). Odd, no? Perusing though the documentation told me that the default window size is (-1,-1). If the code detects this, it will set it to  (20, 20) as sort of a “indicator” that something is not right. As opposed to say printing something out to standard error, or something useful like that. Anyways, I had a flash that I  might be passing in bad data. In any other strongly typed language passing data this bad would wreak all kinds of havoc. In this library it just keeps on trucking. I changed my call to the class to match what the API says it should be, and lo-and-behold getClientSize() began returning the correct size every time. So, the lesson here is if you pass bad/incorrect data in python/wxpython, that is no guarantee that you will be warned. It seems like it will try its best to keep on going. I get run time errors in python all the time for things like this, but this is the first time I’ve seen it let something that seems so wrong just slip by. Which can make debugging such a pain.