IronPython programming can be harder than it looks!

After playing around with IronPython for a few months, I definitely like how easy it is to manipulate objects. Everything is truly open, and if you want to attach one object to another or pass a function around as a variable then "it just works". I have mainly been using IronPython for fun, but right now I would be a bit scared to use such a fluid language for a structured large scale production application: The lack of static typing and compile time checks would make we wary of using IronPython for "real code" instead of just scripting. I stumbled on a video of Giles Thomas on Channel 9 (posted in March 2008 but mystically appeared in my RSS reader this afternoon) and it sounds like Resolver Systems had similar concerns but combined IronPython with Test Driven Development to build a solid foundation for Resolver One. That way they get plenty of up front testing and don't need to second guess the dynamic nature of programming in python. Seems to have worked well so far, as Resolver One is a rock solid product from my experience.
Usually when somebody says that "it just works", the phrase comes with an asterisk and a long line of small text at the bottom of the page. In my experience with IronPython this is still the case, as there are a few things that are much harder to do than they should be. Michael Foord, another Resolver Systems developer, co-wrote the book on IronPython, and today wrote an article about a case when IronPython code ends up being a bit tricky. If you ever need to get the docstrings from an arbitrary IronPython object, or just want to see a detailed explanation of some of the inner workings of python, the Techie Blog is a great read!