Professional IronPython

Creating an Externally Accessible IronPython Module
 
❘
 
309
Before you can use IronPython from other languages, it’s important to consider the way in which 
IronPython performs tasks. When an IronPython session starts, nothing exists — the environment 
begins with an empty slate. You’ve discovered throughout this book that IronPython calls upon 
certain script files as it starts to configure the environment automatically. These configuration tasks 
aren’t part of the startup; they are part of the configuration — something that occurs after the startup. 
The dynamic nature of IronPython means that all activity begins and ends with adding, changing, 
and removing environment features. There aren’t any compiled bits that you can examine statically. 
Everything in IronPython is dynamic.
When a static language such as C# or Visual Basic.NET attempts to access IronPython, it must 
accommodate the constant change. If you got nothing else out of Chapter 14 but this one fact, then 
the chapter was worth reading. In order to do this, C# and Visual Basic.NET rely upon events because 
they can’t actually accommodate change as part of the language. An event signals a change — an 
IronPython application has modified a class to contain a new method or property. It isn’t just the idea 
that the output or value has changed, but the method or property itself is new. In some cases, C# or 
Visual Basic.NET will also need to deal with the situation where a method or property simply goes 
away as well. The underlying mechanism of events, delegates, and caches is inspired and all but invis-
ible, but to be successful at using the languages together, you must know they’re present.
The differences between dynamic and static languages go further than simply not knowing what code 
will execute next in a dynamic language. There’s also the matter of data typing. A static language 
assigns a type to the data it manages, which means that the compiler can make assumptions about the 
data and optimize access to it. A dynamic language also assigns types to the data it manages, but only 
does so at run time and even then the data type can change. Now, consider how this changeability 
complicates the matter of marshaling data from one language to the other. Because the data no longer 
has a stable type, the marshaling code can’t assume anything about it and must constantly check type 
to ensure the data it marshals appears in the right form in the target language.
The difference between dynamic and static languages, at least from a programming perspective, 
comes down to flexible coding and data typing. Everything else you may have heard either relates to 
differences between any two languages (such as the need to marshal data) or the political drama of 
which tool works best. This book won’t endeavor to tell you what tool to use. Certainly, I don’t tell 
anyone that a hammer works best for driving screws or that screwdrivers make wonderful ice picks 
(not that I believe either of these statements myself). The tool you use for a particular task is the one 
you can use best or the one called for by a particular job requirement. The point of this chapter and 
the rest of the book is to demonstrate that dynamic and static languages can work together success-
fully and in more than one way. The tool you use is up to you.